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Abstract 


The Guidance and Control Software (GCS) project was the 
last in a series of software reliability studies conducted at 
Langley Research Center between 1977 and 1994. The technical 
results of the GCS project were recorded after the experiment 
was completed. Some of the support documentation produced as 
part of the experiment, however, is sending an unexpected role 
far beyond its original project context. Some of the software used 
as part of the GCS project was developed to conform to the 
RTCA/DO-178B software standard, "Software Considerations in 
Airborne Systems and Equipment Certification, " used in the civil 
aviation industry. That standard requires extensive 
documentation throughout the software development life cycle, 
including plans, software requirements, design and source code, 
verification cases and results, and configuration management 
and quality control data. The project documentation that 
includes this information is open for public scrutiny without the 
legal or safety implications associated with comparable data 
from an avionics manufacturer. This public availability has 
afforded an opportunity to use the GCS project documents for 
DO-178B training. This report provides a brief oven’iew of the 
GCS project, describes the 4-volume set of documents and the 
role they are playing in training, and includes the verification 
documents from the GCS project. 


1 Introduction and Background on Software Error Studies 

As the pervasiveness of computer systems has increased, so has the desire and obligation to 
establish the reliability of these systems. Reliability estimation and prediction are standard 
activities in many engineering projects. For the software aspects of computer systems, however, 
reliability estimation and prediction have been topics of dispute, especially for safety-critical 
systems. A primary challenge is how to accurately model the failure behavior of software such 
that numerical estimates of reliability have sufficient credibility for systems where the probability 
of failure needs to be quite small, such as in commercial avionics systems (ref. 1). A second 
challenge is how to gather sufficient data to make such estimates. Software reliability models are 
not used in the civil aviation industry, for example, because “currently available methods do not 
provide results in which confidence can be placed to the level required for this purpose.” (ref. 2) 

In an effort to develop methods to credibly assess the reliability of software for safety-critical 
avionics applications, Langley Research Center initiated a Software Error Studies program in 
1977 (ref. 3). A major focus of those studies was on generating significant quantities of software 
failure data through controlled experimentation to better understand software failure processes. 
The intent of the Software Error Studies program was to incrementally increase complexity and 
realism in a series of experiments so that the final study would have statistically valid results, 
representative of actual software development processes. 

The Software Error Studies program started with initial investigations by the Aerospace 
Corporation to define software reliability measures and data collection requirements (ref. 4-6). 



Next, Boeing Computer Services (BCS) and the Research Triangle Institute (RTI) conducted 
several simple software experiments with aerospace applications including missile tracking, 
launch interception, spline function interpolation, Earth satellite calculation, and pitch axis 
control (refs. 7-11). The experiment design used in these studies generally involved a number of 
programmers (denoted n) who independently generated computer code from a given specification 
of the problem to produce n versions of a program. In these experiments, no particular software 
development standards or life-cycle models were followed. Because the problems were relatively 
small and simple, the versions were compared to a known error-free version of the program to 
obtain information on software errors. 

Although the initial experiments were small and simplistic compared with real-world avionics 
development, they yielded some interesting results that have influenced software reliability 
modeling. The BCS and RTI studies showed widely varying error rates for faults. This finding 
refuted a common assumption in early software reliability growth models that faults produced 
errors at equal rates. These studies also provided evidence of fault interaction where one fault 
could mask potentially erroneous behavior from another fault, or where two or more faults 
together cause errors when alone they would not. (ref. 12) Additional investigations with 77 - 
version programs (ref. 13) found that points in the input space that cause an error can cluster and 
form “error crystals”. Extrapolating this finding to aerospace applications, where input signals 
tend to be continuous in nature, the error crystals may manifest themselves as clusters of 
successive faults that could have unintended consequences, (ref. 14) 

The last project in the Software Error Studies program was the Guidance and Control Software 
(GCS) project. It built on the previous experiments in two ways: (1) by requiring that the software 
specimens for the experiment be developed in compliance with current software development 
standards, and (2) by increasing the complexity of the application problem (ref. 15). At the time 
of the GCS project, the RTCA/DO-178B guidelines, "Software Considerations in Airborne 
Systems and Equipment Certification," (ref. 2) were the primary standard sanctioned by the 
Federal Aviation Administration (FAA) for developing software to be approved for use in 
commercial aircraft equipment (ref. 16). The DO-178B document describes objectives and 
design considerations to be used for the development of software as well as verification, 
configuration management, and quality assurance activities to be performed throughout the 
development process. The DO-178B guidelines were selected as the software development 
standard to be used for the GCS specimens. 

The software application selected for the GCS project, as the title indicates, is a guidance and 
control function for controlling the terminal descent trajectory of a planetary lander vehicle. This 
terminal descent trajectory is the same fundamental trajectory referred to as the “seven minutes of 
terror” in the entry, descent, and landing phase of a planetary mission, such as the recent Phoenix 
Mars Lander (ref. 17). For the GCS project, the software requirements were reverse engineered 
from a simulation program used to study the probability of success of the original NASA Viking 
Lander mission to Mars in the 1970s (ref. 18). It is important to emphasize that the software 
requirements documented for the GCS project, while realistic, are not the actual software 
requirements used for NASA’s Viking Lander or any other planetary landers. 

For the GCS experiment, two 1 teams of software engineers were each tasked to independently 
design, code, and verify a GCS program, following the software development guidance in DO- 
178B, as closely as possible. In addition to those teams, another GCS version was produced, 
without the constraint of compliance with DO-178B, to aid development and verification of the 
requirements and simulation environment. Once all versions were complete, data on residual 


1 The original plan for the GCS project called for three independent teams. Due to funding constraints, 
only two teams were able to complete the project. 
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errors was supposed to be collected by running all the versions simultaneously in a simulation 
environment, and using any discrepancies among the results of the versions as possible 
indications of errors. 

Results of the operational simulations and data collection are described in (ref. 15). The 
purpose of this report is not to repeat those results, but to disseminate some of the project 
documentation that has an unanticipated utility beyond its original project context. The project 
documentation of interest is the documentation developed by the teams required to comply with 
the DO-178B standard. That standard requires extensive records of all of the software 
development life cycle activities. For the GCS project, those records included 18 documents 
consisting of life cycle plans, development products including requirements and source code, 
verification cases and results, and configuration management and quality control data. 
Comparable data from a commercial avionics system would not be available for public review 
because of proprietary and other legal considerations. The GCS project documentation is not 
subject to those considerations because it is not data from an actual operational, or even 
prototype, system. But, the data has sufficient realism to provide a window into the types of 
activities and data involved in the production of DO- 178 compliant software, which makes the 
GCS documentation desirable from a training perspective. 

The remainder of this report provides a brief overview of aspects of the GCS project relevant 
to using the documentation for training. This information includes a description of the GCS 
application, a synopsis of the software development processes used to follow the DO-178B 
guidance, and the data that was generated as a result. Because the complete set of compliance 
documents is large, the documents have been divided into four sets (planning, development, 
verification, and other integral process documents) contained in separate volumes of this report. 
Volume 3 includes in Appendices A-D all of the GCS documents, aside from planning, generated 
as part of the verification process. 

2 Guidance and Control Software Application 

The requirements for the GCS application focus on two primary functions: (1) to provide 
guidance and engine control of the lander vehicle during its terminal phase of descent onto the 
planet's surface, and (2) to communicate sensory information to an orbiting platform about the 
vehicle and its descent. Figure 1 shows a sketch of the lander vehicle, taken from (ref. 18), noting 
the location of the terminal descent propulsion systems. 

The guidance package for the lander vehicle contains sensors that obtain information about the 
vehicle state and environment, a guidance and control computer, and actuators providing the 
thrust necessary for maintaining a safe descent. The vehicle has three accelerometers (one for 
each body axis), one Doppler radar with four beams, one altimeter radar, two temperature 
sensors, three strapped-down gyroscopes, three opposed pairs of roll engines, three axial thrust 
engines, one parachute release actuator, and a touch down sensor. The vehicle has a hexagonal, 
box-like shape; three legs and a surface sensing rod protrude from its undersurface. 

In general, the requirements for the planetary lander only concern the final descent to the 
surface. Figure 2 shows a sketch of the phases of the terminal descent trajectory. 
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After the lander has dropped from orbit, the software controls the engines of the vehicle to the 
surface of a planet. The initialization of the GCS starts the sensing of vehicle altitude. When a 
predefined engine ignition altitude is sensed by the altimeter radar, the GCS begins guidance and 
control of the lander. The axial and roll engines are ignited; while the axial engines are warming 
up, the parachute remains connected to the vehicle. During this engine warm-up phase, the 
aerodynamics of the parachute dictate the vehicle’s trajectory. Vehicle attitude is maintained by 
firing the engines in a throttled-down condition. Once the main engines become hot, the 
parachute is released and the GCS performs an attitude correction maneuver and then follows a 
controlled acceleration descent until a predetermined velocity-altitude contour is crossed. The 
GCS then attempts to maintain the descent of the lander along this predetermined velocity- 
altitude contour. The lander descends along this contour until a predefined engine shut off 
altitude is reached or touchdown is sensed. After all engines are shut off, the lander free-falls to 
the surface. 

The software requirements for this guidance and control application are contained in a 
document called the Guidance and Control Development Specification (in Volume 2). As 
mentioned earlier, the initial requirements for this application were reverse engineered from a 
simulation program used to study the probability of success of the original NASA Viking Lander 
mission to Mars. Prior to use in the experiment, the requirements were revised to make them 
suitable for use in an //-version software experiment. Each of the GCS programs for the 
experiment were developed from the same requirements document. 

3 Software Life Cycle Processes and Documentation 

Having some of the project teams adhere to the DO-178B guidelines as they created a software 
version for the experiment was a significant element of the GCS project, requiring the 
development and tracking of numerous software engineering artifacts not normally associated 
with a software engineering experiment. The purpose of DO-178B is to provide guidelines for 
the production of software such that the completed implementation performs its intended function 
with a level of confidence in safety satisfactory for airworthiness. Along with the production of 
software is the generation of an extensive set of documents recording the production activities. 

DO-178B defines software development activities and objectives for the development life 
cycle of the software, and the evidence that is needed to show compliance. The life-cycle 
processes are divided into planning, development, and integral processes. The planning process 
defines and coordinates the software development processes and the integral processes. The 
software development processes involve identification of software requirements, software design 
and coding, and integration; that is, the development processes directly result in the software 
product. Finally, the integral processes function throughout the software development processes 
to ensure integrity of the software products. The integral processes include software verification, 
configuration management, and quality assurance processes. Section 11 of DO-178B describes 
data that should be produced as evidence of performing all of the life cycle process activities (see 
Table 1). 

For the GCS project, some of this data was common for all of the teams, and other data was 
intended to be specific to each team. For example, each team worked with the same plans, 
standards, and requirements. Then, each individual team was responsible for independently 
developing their own design, code, and corresponding verification data. To distinguish the 
versions, each team was assigned a planetary name: Mercury, Venus, and Pluto 2 . 


2 At the time the GCS experiment was conducted, Pluto had not yet been relegated to non-planet status. 
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Table 1. Life Cycle Data 


Planning Process 
Documents 

• Plan for Software Aspects of 
Certification 

• Software Development Plan 

• Software Verification Plan 

• Software Configuration 
Management Plan 

• Software Quality Assurance 
Plan 

• Software Requirements 
Standards 

• Software Design Standards 

• Software Code Standards 


Development Process 
Documents 

• Software Requirements Data 

• Design Description 

• Source Code 

• Executable Object Code 


Integral Process 
Documents 

• Software Verification Cases and 
Procedures 

• Software Verification Results 

• Software Life Cycle Environment 
Configuration Index 

• Software Configuration Index 

• Problem Reports 

• Software Configuration 
Management Records 

• Software Quality Assurance 
Records 

• Software Accomplishment 
Summary 


The DO-178B data associated with the development of the Pluto version of the GCS was 
selected for publication. Most of the GCS documents correspond directly with the life cycle data 
listed in Table 1. All together, the documentation includes over 1000 pages. So, for 
dissemination purposes, the Pluto data was divided into the following 4 subsets: 

Volume 1: Planning Documents 

• Plan for Software Aspects of Certification of the Guidance and Control Software Project 

• Software Configuration Management Plan for the Guidance and Control Software Project 

• Software Quality Assurance Plan for the Guidance and Control Software Project 

• Software Verification Plan for the Guidance and Control Software Project 

• Software Development Standards for the Guidance and Control Software Project 

Volume 2: Development Documents 

• Guidance and Control Software Development Specification 

• Design Description for the Pluto Implementation of the Guidance and Control Software 

• Source Code for the Pluto Implementation of the Guidance and Control Software 

Volume 3: Verification Documents 

• Software Verification Cases and Procedures for the Guidance and Control Software Project 

• Software Verification Results for the Pluto Implementation of GCS 

• Review Records for the Pluto Implementation of the Guidance and Control Software 

• Test Results Logs for the Pluto Implementation of the Guidance and Control Software 
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Volume 4: Other Integral Processes Documents 

• Software Accomplishment Summary for the Guidance and Control Software Project 

• Software Configuration Index for the Guidance and Control Software Project 

• Problem Reports for the Pluto Implementation of the Guidance and Control Software 

• Support Documentation Change Reports for the Guidance and Control Software Project 

• Configuration Management Records for the Guidance and Control Software Project 

• Software Quality Assurance Records for the Guidance and Control Software Project 

Appendices A-D contain all of the original verification documents, except for verification 
planning, for the GCS Project. Software Verification Cases and Procedures for the Guidance 
and Control Software Project, in Appendix A, specifies the procedures for conducting reviews, 
analysis, and testing, and describes the test cases that meet Level A requirements for verification. 
The results of the review and analysis activities for the requirements and design are recorded in 
Review Records for the Pluto Implementation of the Guidance and Control Software, in Appendix 
B; and. Software Verification Results for the Pluto Implementation of the Guidance and Control 
Software, in Appendix C, contains the results of all of the testing activities. The Test Results 
Logs in Appendix D records the actual pass/fail results of the testing. 

The content of the documents in the appendices has not been altered from the original versions 
produced during the project. 

4 Role in Training 

At the time of the GCS project, there was no publicly available information, such as templates, 
or examples, or training courses, to help a novice developer generate the type of evidence that a 
certificating authority would expect to see to demonstrate compliance with DO-178B. As 
mentioned earlier, compliance data from a real avionics system is not typically available for 
public review because of various legal and safety considerations. For example, an avionics 
manufacturer would likely consider the design and implementation of a system to be proprietary. 
Those considerations do not apply to the data from the GCS project, because neither the 
requirements nor the software versions represent an actual system with safety, liability, or other 
considerations. 

In addition to the availability of data, the GCS requirements and DO-178B compliance data 
are sufficiently realistic to serve as an example of a DO-178B project: one that is small enough in 
scale to be studied in a training course. The GCS documentation provides a window into the 
activities and data produced throughout the development life cycle to comply with DO-178B. 
Because the Federal Aviation Administration (FAA) was aware of the GCS project, they 
recognized the potential value of the documentation for training. The FAA has designed software 
training to include a case study portion that addresses avionics software issues that arise from the 
application of the DO-178B guidelines. The case study gives students the opportunity to use 
auditing techniques to identify flaws in lifecycle data. Because the GCS data was produced by 
novices, there are plenty of flaws to find. 

5 Summary 

From 1977-1994, NASA Langley Research Center conducted a Software Error Studies 
program that generated data that provided insights into the software failure process and into 
conducting software engineering experiments as well. The GCS project was the final experiment 
in that program. A unique feature of the GCS project was the requirement for some of the 
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software specimens used in the experiment to conform to the RTCA/DO-178B software standard, 
"Software Considerations in Airborne Systems and Equipment Certification," used in the civil 
aviation industry. The project documentation produced to meet that requirement has had the 
unanticipated benefit of serving as case study material in software certification training long after 
the conclusion of the original experiment. Volume 3 of this report contains all of the verification 
documents from the GCS project. Other volumes of this report contain the rest of the GCS 
compliance data including planning, development, and configuration management and quality 
assurance documents. 
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A.l Introduction 


The purpose of this document, as described in Section 11.13 of Requirements and Technical 
Concepts for Aviation RTCA/DO-178B, "Software Considerations in Airborne Systems and 
Equipment Certification" (ref. A.2), is to provide details about how software verification process 
activities are to be implemented for the Guidance and Control Software (GCS) project. As stated 
in the preface, the development and verification of this software strictly follows guidelines 
described in DO-178B. This document focuses on review and analysis as well as testing 
methods. In particular, this document will provide details on procedures for conducting reviews 
and analysis, describe the test cases that meet Level A requirements, and test procedures to use 
for verification. Methods adopted for tracking test cases as well as accounting for test coverage 
will also be discussed. 

As stated in the Software Verification Plan, GCS verification activities are independent from 
the development process. The development process produces artifacts that must undergo some 
level of verification as described in DO-178B. Figure A.l gives an overview of verification 
activities for the GCS project and how they are related to the development processes. The 
procedures for conducting the verification activities given in Figure A.l are described in the 
sections below. 


Development Process 


Verification Activity 


Transition Criteria 


GCS Specification 

Requirements SW Requirements Data 


Beyond scope of GCS project 
No system requirements available. 


SW Requirements approved 
by project management 


Design 


Design Description 


Design Review 


Design Description reviewed and 
approved by all inspectors 


Code 


Source Code 


Code Review 


Source Code reviewed and 
approved by all inspectors. 


Source Code/Executable Code 

Integration Requirements-Based Testing 

• Low-level Tests 
(functional unit) 

• SW Integration Tests 
(subframe, frame, trajectory) 

• No HW/SW integration Tests 


Meet 100% requirements coverage 
(Passed all requirements based test 
cases.) 


Structural -based Tests Meet 100% Multiple Condition / 

Decision Coverage. 

(Which also meets: 

100% Decision Coverage 
100% Statement Coverage) 


Figure A. 1 : Overview of verification activities. 
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The GCS project includes the development of two GCS implementations, Mercury and Pluto. 
Both implementations are developed based on the same requirements and subject to the same 
review and test procedures. Similarly, both are tested with the same set of requirements-based 
test cases. Since the methods for reviewing design and code and developing test cases and 
accounting for coverage are the same for both the Mercury and Pluto implementations, this 
document will treat those topics generically. Additionally, since requirements-based test cases 
will be identical for both implementations, there will only be one set of requirements test cases 
for both Pluto and Mercury and one set of procedures for executing those test cases. 

A.2 Review and Analysis Procedures 

As stated in sections 6.1 to 6.3 of DO-178B, one of the general objectives of the software 
verification process is to verify that "the high-level requirements have been developed into 
software architecture and low-level requirements that satisfy the high-level requirements." 
Additionally, the results of the coding process must be verified to ensure correctness and 
accuracy with respect to the low-level requirements. During the Transitional Design process of 
the GCS project, the programmers create a detailed software design that meets the requirements 
defined in Version 2.3 (including formal modifications) of the GCS Specification. 

For the GCS project, the review of the detailed design and the source code for each 
implementation will consist of a series of inspections that are executed by a structured, team 
approach. This inspection approach is based on the Design Review and Assessment Technical 
Assessment Procedures (DRATAP) used by the U. S. Army Missile Command (ref. A.3) and has 
been tailored to fulfill the requirements of DO-178B and the GCS project. The DRATAP itself is 
a version of the Fagan Inspection methodology (ref. A.4) which has been tailored to meet the 
needs of the Missile Command. Though the procedure for both the design and the code review 
will be basically identical, the objectives in each are slightly different with respect to the product 
being reviewed. 

The inspection methodology is based on a team approach where all members of the review 
team have specific roles to perform. For the GCS project, there is a unique review team for each 
implementation. Each review team consists of the Programmer and Verification Analyst assigned 
to the implementation under review, the System Analyst, and the Software Quality Assurance 
representative. Prior to the start of the actual inspection sessions, an overview meeting will be 
held to review the procedures and roles for the inspections and distribute all materials that are 
needed to perform the inspections. During the Inspection Sessions, the review team will discuss 
and identify defects, clarity problems, and concerns about the product under review. 

This Review Procedure identifies the tools used during the inspection, the roles of the review 
team members during the inspections, the completion criteria, and the data that result from the 
completed process. The verification tools needed for the inspections include the Review 
Procedures (section A. 5), the Design Review Checklist (section A. 6) or the Code Review 
Checklist (section A.9), the Traceability Matrix (section A.7) and supplemental data, and 
Individual Inspection Preparation Logs (section A.8). The Inspection Logs can be produced 
electronically and do not have to exactly follow the format given in section A.8, but all pertinent 
information from section A.8 should be included. 

The Review Checklist will be utilized by each member of the review team as a guide during 
the inspection process to aid in finding defects and problems. The checklist is composed of a 
series of questions about the detailed design with a yes/no column to be completed with the 
questions. The questions are phrased such that a "no" response may indicate a defect or a 
problem that requires further investigation and results in the generation of a Problem Report. 
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The GCS Requirements Traceability Matrix is also used during the inspection process. The 
Traceability Matrix provides an organized list of the requirements, derived from the GCS 
Specification. Each inspector with the exception of the programmer will use the Traceability 
Matrix and supplemental data during individual inspections; however, only one Traceability 
Matrix will result from a complete review. It is the responsibility of the Moderator of the 
inspection team to complete the Traceability Matrix for each implementation's review and to add 
low-level as well as any derived requirements to the matrix as necessary. The traceability data 
document is a supplement to the matrix, and provides clarification of requirements and 
verification criteria. The Traceability Matrix will be completed when the entire review process is 
finished. There will be a Traceability Matrix for each implementation. The Traceability Matrix 
will be the same for each implementation at the start of the Design Reviews. According to the 
DO-178B guidelines, it is also necessary to trace the derived requirements through the 
verification activities. As the Design Reviews progress, the Traceability Matrix for each 
implementation may be modified as low-level and/or derived requirements are identified. The 
Moderator will ensure that all derived requirements are added to the Traceability Matrix. 

The Traceability Matrix will be used during the verification activities to track the requirements 
through each implementation's design, source code, and testing of its executable image. In the 
Traceability Matrix, columns are provided for each verification activity: design review, code 
review, and all phases of testing. Consequently, one of the outputs of a review should be a 
Traceability Matrix that has been modified to include any low-level and/or derived requirements 
that are identified and justified, and the P-Spec number or module name from the artifact where 
each requirement is addressed. 

A Problem Report is generated when it is determined that a product (Design, Code, 
Executable) contains a defect. The project's Problem and Action Reporting Procedures are used 
to track errors and the changes made to the design and any other software development artifacts 
as a result of errors. A Problem Report generated during a review includes detailed information 
about the defect; a description of the problem including a reference to the document and 
document section that justifies the problem report, the location in the design (P-Spec#) or source 
code (Module name), the implementation's name, and other critical information. An example of a 
Problem Report and instructions for completing it can be found in the Software Development 
Standards. 

The Traceability Matrix is given in the Software Verification Plan and will be under 
configuration management. Any changes made to these documents must conform to the 
Configuration Management Plan. 

The following section describes the role of all the participants in the inspection sessions. 

A.2.1 Review Team 

As stated above, a review of the detailed design or source code for each implementation will 
be conducted by a team through a series of inspections. Except for the Moderator, all members of 
the review team will be Inspectors. In addition, the following members of the review team will 
have an additional role in the inspection sessions: the Software Quality Assurance (SQA) 

representative will be the Moderator, the Programmer will be the Reader, and the Verification 
Analyst will be the recorder. Each of these roles is described below. 

A.2.2 Inspector 

Each Inspector performs a critical reading of the product under review with the intent of 
identifying defects (as described above) in the product. The Review Procedures, checklist, and 
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Inspection Log will be supplied to each Inspector at the overview meeting to aid in the review. 
The Traceability Matrix will also be supplied to the Verification Analyst and the System Analyst. 
The critical reading of the assigned portion of the product to be inspected must be completed 
before the first inspection session. Each Inspector should bring the completed checklist and a list 
of any problems noted during the review (recorded on the Inspection Logs) to the inspection 
sessions. The specific activities of an Inspector are: 

1. Attend the Overview Meeting and all Inspection Sessions. 

2. Review the verification procedures and tools (checklist, Inspection Logs, etc.) assigned by the 
Moderator. 

3. Review the product description and complete the checklist. 

4. Record suspected defects on the Inspection Log. 

5. Submit the completed Inspection Log to the Moderator at least four hours prior to the 
Inspection Session. 

A.2.3 Moderator 

The Moderator provides the leadership for the inspection sessions. The Moderator performs 
the following activities: 

1 . Chairs the Inspection Sessions and the Overview Meeting. 

2. Schedules the Inspection Sessions and the Overview Meeting. 

3. Collects all materials necessary for the Inspection Sessions and distributes these to the review 
team. These materials include the product description, appropriate Review Checklist, Review 
Procedures, appropriate Standards, blank Inspection Logs, and any other documentation 
deemed necessary. Note that there is only one "official" Traceability Matrix that is produced 
by the review, and this is will become part of the Software Verification Results. 

4. Ensures that all time guidelines are followed. 

5. Ensures that all issues are resolved and/or recorded to the satisfaction of the team. 

6. Ensures that the appropriate column of the Traceability Matrix is completed with the design 
P-Spec or code module number that satisfies the requirement or a Problem Report number, 
adding low-level and/or derived requirements to the Traceability Matrix as necessary. 

7. Ensures that any follow-up actions are documented, assigned for action, and resolved; and 
schedules any necessary follow-up sessions. 

A.2.4 Reader 

During the Overview meeting, the Reader will give a brief description of the product under 
review and the supporting documents. At the Inspection Session, the Reader guides the team 
through each part of the product and must answer questions that arise about the product from the 
other members of the review team. The parts of the product that are identified in the Inspections 
Logs as suspect will be examined in detail. The Reader also performs the function of an 
Inspector. 
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A.2.5 Recorder 


The Recorder documents problems noted in an Inspection Session and initiates the necessary 
Problem Reports. At the conclusion of the review, the Recorder will produce an electronic copy 
of the Review Minutes. The Recorder also performs the function of an Inspector. 

A.2.6 Overview Meeting 

The purpose of this meeting is to ensure that the material to be reviewed and the associated 
requirements are understood by all members of the review team. During this meeting, the 
Moderator will discuss the scope of and procedures and tools for the inspections and will discuss 
the role of each of the participants. The Moderator will also distribute the materials necessary to 
inspect the product. These materials include the Design or Code Description, Review Procedures, 
Review Checklist, Design or Code Standards, and blank Inspection Logs. All members of the 
review team are required to attend this meeting. The Overview Meeting should be held at least 
twenty-four man hours (which may be as many as 6 days due to the part-time schedules of some 
of the GCS participants) before the scheduled time for the first inspection session. 

A.2.7 Procedures for the Inspection Sessions 

Prior to the Inspection Sessions, there is a period of time devoted to preparation for the 
inspections. This preparation specifically consists of the review and assessment of the product by 
each Inspector. Inspectors should review the product in detail, using the appropriate checklists. 
Any suspected defects should be noted on the Inspection Log, and this form should be returned to 
the Moderator at least four hours prior to the Inspection Session. The log should cite specific 
requirements, Design Standards, or Code Standards for each suspected defect. The review team 
is also responsible for identifying derived requirements in the product. All inspectors should be 
allotted at least twenty-four man hours for preparation for the inspections. 

During the Inspection Sessions, the Reader guides the team through the product and answers 
questions about the product from the members of the review team. All problems noted by the 
Inspectors and logged on the Inspection Logs should be discussed. The Programmer should 
provide sufficient justification for all derived requirements, and the derived requirements should 
be added to the Traceability Matrix to track their implementation throughout the development 
process. The Recorder will initiate all necessary Problem Reports. 

The inspection sessions should be limited to two hours per session, and no more than three 
sessions should be scheduled during any given week. The inspection sessions should be repeated 
until all of the product has been inspected. The following guidelines will be followed during each 
inspection session: 

1. Inspectors should bring all documents and notes, including a copy of the Inspection Log, to 
the session. 

2. Inspectors should avoid suggesting solutions to defects. 

3. If no resolution to an issue is achieved after a reasonable discussion, the issue should be 
logged for later action and continue to the next problem. 

4. If a session lasts over two hours, the session should be stopped and a continuation scheduled 
(within one or two days). 


A- 9 



5. After the session, the Recorder should prepare Problem Reports for all items determined to be 
problems by the Inspection Team. 

6. Each implementation's Review notes, compiled by the Recorder, will be put into an informal 
document, called Review Minutes. 


The following data will result from the completed Design or Code Review process: a copy of 
the Review minutes, the Traceability Matrix with the appropriate portion completed including the 
addition of any derived requirements, and Problem Reports. The SQA Representative is 
responsible for completing a report on the Design or Code Review Process. The SQA 
Representative is also responsible for ensuring that all Problem Reports are addressed, tracked, 
and satisfactorily closed (see the Software Quality Assurance Plan for details). The review 
process is complete when the product has been completely reviewed according to the inspection 
procedures and all reported problems are resolved. 

A.3 Test Case Overview 

This section describes the requirements-based test cases developed for GCS testing as required 
by DO-178B section 1 1.13b. Requirements-based test cases are developed for the functional unit, 
subframe, frame, and trajectory testing. In this section, test cases are organized by the functional 
units, subframe, frame and trajectory. Traceability of requirements to test cases is established in 
Table A. 10-1 in section A. 10. As stated in the Software Verification Plan, there are two 
categories of requirements-based test cases at the functional unit level. These are the Normal 
Range cases and the Robustness cases. Each functional unit test case name will contain the “NR” 
or “RO” differentiate cases from each group. Test cases have been devised to provide the 
coverage as described in the Software Verification Plan . 

Equivalence class coverage is the first coverage requirement in DO-178B. Equivalence class 
partitioning, as described in the Software Verification Plan, has been applied to GCS data 
elements and the equivalence classes given in Table A.9-1. Cases that test each equivalence class 
are given in Table A. 9-2. For GCS purposes, variables from the RUN PARAMETERS data 
store are considered not to change. Even though these variables are listed in the input list of 
functional units in the GCS Specification, they will not be tested as part of the input space of the 
functional units. Another exception to creating equivalence class for GCS variables is that some 
variables, while defined as integers in the actual code, are used as enumerated types. These 
variables are tested as state transitions. 

Data for each test case originates in its respective data files as given in the tables below. 
These data files are used in the procedure given in section A.5 to generate the test-input and 
expected-results files (these are also given in tables below). Each file is written in FORTRAN 
namelist format and contain the values of variables in all four data stores, and are the actual files 
used to actually test the code. The test-input file contains the input values of variables before the 
functional unit is executed. The expected-results file contains the value of what the variables 
should be after the functional unit has executed. 

Test stubs (or test drivers) have been written to insure that the integrity of the four data stores 
are maintained. When each test case is executed, using the execution procedure described in the 
test case execution section below, the expected-result file is compared to the values generated by 
the tested code. All four data stores are compared even though the tested code may only effect 
several variables in a single data store. This ensures that the remaining data elements not 
inadvertently overwritten during execution of a functional unit test case. 
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There is a general problem of verifying history variable rotations when all the variables are the 
same values. It is not possible to verify that a rotation has occurred. This problem is particularly 
acute for the status variables and computation indicators that require histories. In testing the 
history rotation of these variables, it is necessary to introduce alternating patterns so that the 
rotation can be verified. For variables that are matrices, this alternating pattern introduces values 
into matrix elements that would otherwise be zeros. Unfortunately, this is necessary to be sure 
that even those elements are rotated. 

The sections below give a comprehensive listing of requirements-based test cases for each 
functional unit, subframe, frame, and trajectory. Each functional units section gives a list of 
variables being tested, any special conditions that test case has to cover, and a table of all the test 
cases in for that functional unit. Only files specific to each test case are given in tables in this 
section. Other files needed for generating and executing the test cases are given in Table A. 1 1-1 
and Table A.l 1-2 along with test case generation procedures in section A.l 1. 

The first column of each Test Case Table, “Test Case Data File”, gives the name of the data 
file used to generate the test case. A description follows in the second column. The last two 
columns labeled “Test-Input File” and “Expected-Results File” give the files generated by using 
the procedure in section A. 1 1 . 
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A.3.1 ARSP Functional Unit Test Cases 


Table A. 1 gives a listing of all requirements-based test cases for the ARSP functional unit. All 
test cases manipulate the variables: 


ARCOUNTER 
ARALTITUDE 
ARSTATUS 
K ALT 


KALT only needs to be tested for rotation in this functional unit. For this case, the KALT 
rotation can be tested at the same time as testing AR STATUS = FAIL. These two variables are 
independent of each other. To verify upper and lower bounds checking for AR ALTITUDE, the 
various histories of AR ALTITUDE are set beyond the bounds while their corresponding 
AR STATUS histories are set to healthy. This is unrealistic but its the only way to force the 
bounds checks. AR FREQUENCY is also listed in the GCS Specification as an input variable to 
this functional unit but is not tested because it is from the RUN PARAMETERS data store. The 
values assigned to the tested variables are given in the Test Case Data File. 
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Table A. 1: Test cases for ARSP functional unit. 


Test Case Data 
File 

Description 

Test-Input File 

Expected- 
Results File 

arsp ro OOl.m 

Test AR COUNTER out of UPPER bound 

arsp ro OOl.tc 

arsp ro 00 l.ex 

arsp ro 002. m 

Test AR COUNTER out of LOWER bound 

arsp ro 002. tc 

arsp ro 002. ex 

arsp ro 003 .m 

Force extrapolation with AR ALTITUDE[0] out of LOWER 
bound to see if bounds checking messages are executed. 

arsp ro 003 .tc 

arsp_ro_003.ex 

arsp ro 004.m 

Force extrapolation with AR ALTITUDE[1] out of LOWER 
bound to see if bounds checking messages are executed. 

arsp ro 004,tc 

arsp ro 004. ex 

arsp ro 005. m 

Force extrapolation with AR ALTITUDE[2] out of LOWER 
bound to see if bounds checking messages are executed. 

arsp_ro_005.tc 

arsp ro 005. ex 

arsp ro 006.m 

Force extrapolation with AR ALTITUDE[3] out of LOWER 
bound to see if bounds checking messages are executed. 

arsp_ro_006.tc 

arsp_ro_006.ex 

arsp ro 007.m 

Force extrapolation with AR ALTITUDE[0] out of UPPER 
bound to see if bounds checking messages are executed 

arsp_ro_007.tc 

arsp ro 007. ex 

arsp ro 008.m 

Force extrapolation with AR ALTITUDE[1] out of UPPER 
bound to see if bounds checking messages are executed 

arsp ro 008.tc 

arsp ro 008. ex 

arsp ro 009. m 

Force extrapolation with AR ALTITUDE[2] out of UPPER 
bound to see if bounds checking messages are executed 

arsp_ro_009.tc 

arsp_ro_009.ex 

arsp ro OlO.m 

Force extrapolation with AR ALTITUDE[3] out of UPPER 
bound to see if bounds checking messages are executed 

arsp ro OlO.tc 

arsp ro 010. ex 

arsp nr 0 1 1 .m 

Test nonnal extrapolation & test setting AR STATUS =1 & 
K ALT = 1 (row 2 of table 5.4 in Spec.) 

arsp nr 0 1 1 .tc 

arsp nr 01 l.ex 

arsp nr 012.m 

Test for proper setting of AR_STATUS[0] and KALT[0] 
according to row 3 of table 5.4 with no echo returned & 
AR_STATUS[0] = Failed 

arsp nr 012,tc 

arsp nr 012. ex 

arsp nr 013.m 

Test for proper setting of AR_STATUS[0] and K_ALT[0] 
according to row 3 of table 5.4 with no echo returned & 
AR_STATUS[1] = Failed 

arsp nr 013.tc 

arsp nr 013. ex 

arsp nr 014.m 

Test for proper setting of AR_STATUS[0] and K_ALT[0] 
according to row 3 of table 5.4 with no echo returned & 
AR_STATUS[2] = Failed 

arsp nr 014.tc 

arsp nr 014. ex 

arsp nr 015.m 

Test for proper setting of AR_STATUS[0] and K_ALT[0] 
according to row 3 of table 5.4 with no echo returned & 
AR_STATUS[3] = Failed 

arsp nr 015.tc 

arsp nr 01 5. ex 

arsp nr 016.m 

Test Zero - AR COUNTER and setting of AR_STATUS[0] to 
healthy 

arsp nr 016.tc 

arsp nr 016. ex 

arsp nr 017.m 

Test upper bound - AR COUNTER 

arsp nr 017.tc 

arsp nr 017. ex 

arsp ro 018.m 

Test INVALID status - AR_STATUS[0] 

arsp ro 018.tc 

arsp ro 018. ex 

arsp ro 019.m 

Test INVALID status - AR_STATUS[1] 

arsp ro 019.tc 

arsp ro 019. ex 

arsp ro 020. m 

Test INVALID status - AR_STATUS[2] 

arsp ro 020. tc 

arsp ro 020. ex 

arsp ro 021.m 

Test INVALID status - AR_STATUS[3] 

arsp ro 021.tc 

arsp ro 02 l.ex 

arsp nr 022. m 

Test AR ALTITUDE calculation based on AR COUNTER 
and setting of AR_STATUS[0] and K ALT[0] according to 
row 1 of table 5.4 in the Spec. Also test history rotations for 
AR ALTITUDE. AR STATUS[0,2], & K_ALT[0,2] 

arsp nr 022. tc 

arsp nr 022. ex 

arsp nr 023. m 

Test AR ALTITUDE calculation based on AR COUNTER 
and test history rotations for AR ALTITUDE, 
AR_STATUS[1,3], & K_ALT[1,3] 

arsp nr 023. tc 

arsp nr 023. ex 
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A.3.2 ASP Functional Unit Test Cases 


Table A.2 is a listing of all requirements-based test cases for the ASP functional unit. 
Variables involved in the test cases are: 


AACCELERATION 
ACOUNTER 
ATMOSPHERICTEMP 
A STATUS 


Note that A ACCELERATION and A STATUS are variables with a history dimensions. The 
oldest elements in these variables will not require testing since it is discarded after the history 
rotation. 
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Table A.2: Test cases for ASP functional unit. 


Test Case 
Data File 

Description 

Test-Input 

File 

Expected-Results 

File 

aspnrOO 1 .m 

Test A ACCELERATION calculated from A COUNTER & 
ASTATUS set to HEALTHY 

aspnrOO 1 .tc 

aspnrOO 1 .ex 

asp_nr_002.m 

Test AACCELERATION calculated from average & A STATUS set 
to UNHEALTHY 

asp_nr_002.tc 

asp_nr_002.ex 

asp_nr_003.m 

Test UNHEALTHY A STATUS. A ACCELERATION calculated 
from ACOUNTER but previous A_STATUS[1] was UNHEALTHY 

asp_nr_003.tc 

asp_nr_003.ex 

asp_nr_004.m 

Test UNHEALTHY A STATUS. A ACCELERATION calculated 
from A COUNTER but previous A_STATUS[2] was UNHEALTHY 

asp_nr_004.tc 

asp_nr_004.ex 

asp_nr_005.m 

Test UNHEALTHY A STATUS. A ACCELERATION calculated 
from A COUNTER but previous A_STATUS[3] was UNHEALTHY 

asp_nr_005.tc 

asp_nr_005.ex 

asp_nr_006.m 

Test History variable rotation for A ACCELERATION[0-4] & 
A_STATUS[0,2] 

asp_nr_006.tc 

asp_nr_006.ex 

asp_nr_007.m 

Test History variable rotation A STATUS[ 1 ] 

asp_nr_007.tc 

asp_nr_007.ex 

asp_ro_008.m 

Test LOW out of bound for ATMOSPHERIC TEMP 

asp_ro_008.tc 

asp_ro_008.ex 

asp_ro_009.m 

Test HIGH out of bound for ATMOSPHERIC TEMP 

asp_ro_009.tc 

asp_ro_009.ex 

asproO 1 0.m 

Test LOW out of bound for A_COUNTER[l] 

asproO 1 0.tc 

asproO 1 0.ex 

asproO 1 1 .m 

Test LOW out of bound for A_COUNTER[2] 

asproOl l.tc 

asproOl l.ex 

asp_ro_012.m 

Test LOW out of bound for A_COUNTER[3] 

asp_ro_012.tc 

asp_ro_012.ex 

asproO 1 3 .m 

Test HIGH out of bound for A_COUNTER[l] 

asp_ro_013.tc 

asp_ro_013.ex 

asp_ro_014.m 

Test HIGH out of bound for A_COUNTER[2] 

asp_ro_014.tc 

asp_ro_014.ex 

asp_ro_015.m 

Test HIGH out of bound for A_COUNTER[3] 

asp_ro_015.tc 

asp_ro_015.ex 

aspnrO 1 6.m 

Test A COUNTER at zero - based on hueristic! ! 

asp_nr_016.tc 

asp_nr_016.ex 

asp_ro_017.m 

Test A_ACCELERATION[0,x] out of LOWER bound 

asp_ro_017.tc 

asp_ro_017.ex 

asp_ro_018.m 

Test A_ACCELERATION[0,x] out of UPPER bound 

asp_ro_018.tc 

asp_ro_018.ex 

asp_ro_019.m 

Test A_ACCELERATION[0,y] out of LOWER bound 

asp_ro_019.tc 

asproO 1 9. ex 

asp_ro_020.m 

Test A_ACCELERATION[0,y] out of UPPER bound 

asp_ro_020.tc 

asp_ro_020.ex 

asp_ro_02 1 .m 

Test A_ACCELERATION[0,z] out of LOWER bound 

asp_ro_02 1 .tc 

asp_ro_02 1 .ex 

asp_ro_022.m 

Test A_ACCELERATION[0,z] out of UPPER bound 

asp ro 022 .tc 

asp_ro_022.ex 

asp_ro_023 .m 

Test A_ACCELERATION[ 1 ,x] out of LOWER bound 

asp ro 023.tc 

asp_ro_023.ex 

asp_ro_024.m 

Test A_ACCELERATION[ 1 ,x] out of UPPER bound 

asp_ro_024.tc 

asp_ro_024.ex 

asp_ro_025.m 

Test A_ACCELERATION[ 1 ,y] out of LOWER bound 

asp_ro_025.tc 

asp_ro_025.ex 

asp_ro_026.m 

Test A_ACCELERATION[ 1 ,y] out of UPPER bound 

asp_ro_026.tc 

asp_ro_026.ex 

asp_ro_027.m 

Test A_ACCELERATION[ 1 ,z] out of LOWER bound 

asp ro 027.tc 

asp_ro_027.ex 

asp_ro_028.m 

Test A_ACCELERATION[ 1 ,z] out of UPPER bound 

asp_ro_028.tc 

asp_ro_028.ex 

asp_ro_029.m 

Test A ACCELERATION [2 ,x] out of LOWER bound 

asp_ro_029.tc 

asp_ro_029.ex 

asp_ro_030.m 

Test A ACCELERATION [2 ,x] out of UPPER bound 

asp_ro_030.tc 

asp_ro_030.ex 

asp_ro_03 1 .m 

Test A ACCELERATION [2 ,y] out of LOWER bound 

asp_ro_03 1 .tc 

asp_ro_03 1 .ex 

asp_ro_032.m 

Test A ACCELERATION [2 ,y] out of UPPER bound 

asp ro 032.tc 

asp_ro_032.ex 

asp_ro_033.m 

Test A ACCELERATION [2 ,z] out of LOWER bound 

asp ro 033.tc 

asp_ro_033.ex 

asp_ro_034.m 

Test A ACCELERATION [2 ,z] out of UPPER bound 

asp_ro_034.tc 

asp_ro_034.ex 

asp_ro_035.m 

Test A_ACCELERATION[3,x] out of LOWER bound 

asp_ro_035.tc 

asp_ro_035.ex 

asp_ro_036.m 

Test A_ACCELERATION[3,x] out of UPPER bound 

asp_ro_036.tc 

asp_ro_036.ex 

asp_ro_037.m 

Test A_ACCELERATION[3,y] out of LOWER bound 

asp_ro_037.tc 

asp_ro_037.ex 

asp_ro_038.m 

Test A_ACCELERATION[3,y] out of UPPER bound 

asp ro 038.tc 

asp_ro_038.ex 

asp_ro_039.m 

Test A_ACCELERATION[3,z] out of LOWER bound 

asp_ro_039.tc 

asp_ro_039.ex 

asp_ro_040.m 

Test A_ACCELERATION[3,z] out of UPPER bound 

asp_ro_040.tc 

asp_ro_040.ex 

asp_ro_04 1 .m 

Test UNHEALTHY A STATUS. A ACCELERATION calculated 
from A COUNTER but previous A_STATUS[1,I] was INVALID 

asp_ro_04 1 .tc 

asp_ro_04 1 .ex 

asp_ro_042.m 

Test UNHEALTHY A STATUS. A ACCELERATION calculated 
from A COUNTER but previous A_STATUS[1,1] was INVALID 

asp_ro_042.tc 

asp_ro_042.ex 

asp_ro_043.m 

Test UNHEALTHY A STATUS. A ACCELERATION calculated 
from A COUNTER but previous A_STATUS[3,1] was INVALID 

asp_ro_043.tc 

asp_ro_043.ex 

asp_ro_044.m 

Test UNHEALTHY A STATUS. A ACCELERATION calculated 
from A COUNTER but previous A_STATUS[3,2] was INVALID 

asp_ro_044.tc 

asp_ro_044.ex 
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A.3.3 GSP Functional Unit Test Cases 


Table A. 3 gives a listing of all requirements-based test cases for the GSP functional unit. 
Three variables tested by in test cases are: 


ATMOSPHERICTEMP 
GCOUNTER 
G ROTATION 


Note that G ROTATION is in the input list only because it has to be accessed for history 
rotations. 


Table A.3: Test cases for GSP functional unit. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

gspnrOOl.m 

Test History rotation for G ROTATION 

gspnrOO 1 .tc 

gspnrOOl.ex 

gsp_ro_002.m 

Test out of LOWER bound for 
ATMOSPHERICTEMP 

gsp_ro_002.tc 

gsp_ro_002.ex 

gsp_ro_003.m 

Test out of UPPER bound for 
ATMOSPHERIC TEMP 

gsp_ro_003.tc 

gsp_ro_003.ex 

gsp_ro_004.m 

Test out of LOWER bound for G_COUNTER[l] 

gsp_ro_004.tc 

gsp_ro_004.ex 

gsp_ro_005.m 

Test out of LOWER bound for G_COUNTER[2] 

gsp_ro_005.tc 

gsp_ro_005.ex 

gsp_ro_006.m 

Test out of LOWER bound for G_COUNTER[3] 

gsp_ro_006.tc 

gsp_ro_006.ex 

gsp_ro_007.m 

Test out of UPPER bound for G_COUNTER[l] 

gsp_ro_007.tc 

gsp_ro_007.ex 

gsp_ro_008.m 

Test out of UPPER bound for G_COUNTER[2] 

gsp_ro_008.tc 

gsp_ro_008.ex 

gsp_ro_009.m 

Test out of UPPER bound for G_COUNTER[3] 

gsp_ro_009.tc 

gsp_ro_009.ex 
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A.3.4 TSP Functional Unit Test Cases 


Table A.4 is a listing of all requirements-based test cases for the TSP functional unit. All test 
cases manipulate the variables: 


SSTEMP 

THERMO TEMP 


Table A.4: Test cases for TSP functional unit. 


Test Case Data 
File 

Description 

Test-Input File 

Expected-Results 

File 

tsp nr OOl.m 

Test normal range of Both SS TEMP & 

THERMO TEMP - outputs THERMO TEMP 
calculation for equivalence class THERMO TEMP. 1 
and SS TEMP.l 

tsp_nr_00 1 .tc 

tsp nr 00 l.ex 

tsp_nr_002.m 

Test normal range of SS TEMP - outputs SS TEMP 
calculation for equivalence class SS TEMP. 2 

tsp_nr_002.tc 

tsp nr 002.ex 

tsp_nr_003.m 

Test normal range of SS TEMP - outputs SS TEMP 
calculation for equivalence class SS TEMP. 3 

tsp_nr_003.tc 

tsp_nr_003.ex 

tsp ro 004. m 

Test SS TEMP out of upper range - outputs SS TEMP 
calculation for equivalence class SS TEMP. 4 

tsp_ro_004.tc 

tsp_ro_004.ex 

tsp_ro_005.m 

Test SS TEMP out of lower range - outputs SS TEMP 
calculation for equivalence class SS TEMP. 5 

tsp_ro_005.tc 

tsp_ro_005.ex 

tsp nr 006. m 

Test THERMO TEMP - outputs THERMO TEMP 
calculation for equivalence class THERMO TEMP. 2 

tsp_nr_006.tc 

tsp_nr_006.ex 

tsp_nr_007.m 

Test THERMO TEMP - outputs THERMO TEMP 
calculation for equivalence class THERMO TEMP. 3 

tsp_nr_007.tc 

tsp_nr_007.ex 

tsp_ro_008.m 

Test THERMO TEMP - outputs THERMO TEMP 
calculation for equivalence class THERMO TEMP. 4 

tsp_ro_008.tc 

tsp_ro_008.ex 

tsp_ro_009.m 

Test THERMO TEMP - outputs THERMO TEMP 
calculation for equivalence class THERMO TEMP. 5 

tsp_ro_009.tc 

tsp_ro_009.ex 

tsp_ro_010.m 

Force use of THERMO TEMP to test out of LOWER 
bound for THERMO TEMP - Equivalence class 
THERMOTEMP.7 

tsp_ro_010.te 

tsp_ro_010.ex 

tsp ro Oll.m 

Force use of THERMO TEMP to test out of UPPER 
bound for THERMO TEMP - Equivalence class 
THERMOTEMP.6 

tsp_ro_011.tc 

tsp_ro_011.ex 
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A.3.5 TDSP Functional Unit Test Cases 


Table A.6 gives a listing of all requirements-based test cases for the TDSP functional unit. All 
test cases manipulate the variables: 


TDSSTATUS 
TD COUNTER 


Table 5.13 of the GCS Specification does not define the processing that is to occur if the 
TDS STATUS is failed. Furthermore, there are no provisions to prevent this functional unit 
from executing when that occurs. To ensure robustness, it will be necessary to test the behavior 
of the functional unit when TDS STATUS is failed. Table A.5 below lists the missing conditions 
from Table 5.13 of the GCS Specification and gives their respective test case. These cases are 
also given in Table A.6. 


Table A.5: Conditions not given in Table 5.13 of the GCS Specification 


Input 

Output 

Test Case 

TDS_ 

STATUS 

TD_ 

COUNTER 

TD_ 

SENSED 

TDS_ 

STATUS 

Names 

failed 

all zeroes 

unchanged 

failed 

TDSPRO 004.TC 

failed 

all ones 

unchanged 

failed 

TDSPRO 005.TC 

failed 

mixture of ones 
& zeroes 

unchanged 

failed 

TDSPRO 006.TC 


Table A.6: Test cases for TDSP functional unit. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

tdspnrOO 1 .m 

Test healthy status & all counter bits off 

tdspnrOO 1 .tc 

tdspnrOOl.ex 

tdsp_nr_002.m 

Test healthy status & all counter bits on 

tdsp_nr_002.tc 

tdsp_nr_002.ex 

tdsp_nr_003.m 

Test healthy status & mixed counter bits 

tdsp_nr_003.tc 

tdsp_nr_003.ex 

tdsp_ro_004.m 

Test unhealthy status & zero counter 

tdsp_ro_004.tc 

tdsp_ro_004.ex 

tdsp_ro_005.m 

Test unhealthy status & all counter bits on 

tdsp_ro_005.tc 

tdsp_ro_005.ex 

tdsp_ro_006.m 

unhealthy status & mixed counter bits 

tdsp_ro_006.tc 

tdsp_ro_006.ex 

tdsp_ro_007.m 

Tests INVALID TDS STATUS 

tdsp_ro_007.tc 

tdsp_ro_007.ex 
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A.3.6 TDLRSP Functional Unit Test Cases 


Table A. 8 is a listing of all test cases for the TDLRSP functional unit. All test cases 
manipulate the variables: 


FRAMECOUNTER TDLRCOUNTER 

FRAMEBEAMUNLOCKED TDLRSTATE 
K MATRIX TDLR VELOCITY 


For robustness testing purposes, Table 5.1 1 of the GCS Specification is missing several cases 
that should be tested. These conditions are given in Table A.7 below. Note that the 
Beam lock time calculated by: 


Beam lock time = DELTA T *(FRAME_COUNTER - FRAME BEAM UNLOCKED) 

Table A.7 also identifies the test cases for each of those conditions. These cases are also 
repeated in Table A. 8. 


Table A.7: Conditions not given in Table 5.11 of the GCS Specification. 


Input 

Output 

Test Case 

TDLR_ 

STATE 

TDLR_ 

COUNTE 

R 

Beam Jock Jime 

> 

TDLRLOCKTIME 

TDLR_ 

STATE 

FRAME_BEAM_ 

UNLOCKED 

Names 

locked 

± 0 

d 

locked 

Unchanged 

TDLRSPRO 006.TC 

unlocked 

9^ 0 

no 

unlocked 

Unchanged 

TDLRSPRO 002.TC 

unlocked 

= 0 

no 

unlocked 

Unchanged 

TDLRSPRO 004.TC 
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Table A.8: Test cases for TDLRSP functional unit. 


Test Case Data 
File 

Description 

Test-Input File 

Expected- 
Results File 

tdlrsp nr OOl.m 

Test: 1) TDLRSTATE - 0 & TDLRCOUNTER != 0 
(line 2 of table 5.1 1) 2) line 16 of table 5.12 2) history 
rotation for TDLR VELOCITY & K MATRIX 

tdlrsp_nr_00 1 .tc 

tdlrsp nr 00 l.ex 

tdlrsp_ro_002.m 

Test: 1) TDLR STATE = 0 & TDLR COUNTER != 0 
but elapsed time < TDLR LOCK TIME (not listed in 
table 5.11) 

tdlrsp_ro_002.tc 

tdlrsp_ro_002.ex 

tdlrsp_nr_003.m 

Test: TDLR STATE = 0 & TDLR COUNTER = 0 
(line 3 of table 5.11) 

tdlrsp_nr_003.tc 

tdlrsp_nr_003.ex 

tdlrsp ro 004. m 

Test: TDLR STATE = 0 & TDLR COUNTER = 0 but 
elapsed time < TDLR LOCK TIME (not listed in table 
5.11) 

tdlrsp_ro_004.tc 

tdlrsp_ro_004.ex 

tdlrsp_nr_005.m 

Test: 1) TDLR STATE = 1 & TDLR COUNTER = 0 
(line 1 of table 5.11) 2) line 1 of table 5.12 (no beams 
in lock) 

tdlrsp_nr_005.tc 

tdlrsp_nr_005.ex 

tdlrsp ro 006. m 

Test: 1) TDLR STATE = 1 & TDLR COUNTER != 0 
(not listed in table 5.11) 2) line 1 of table 5.12 (no 
beams in lock) 

tdlrsp_ro_006.tc 

tdlrsp_ro_006.ex 

tdlrsp_nr_007.m 

Test: Beam 1 in lock (line 2 of table 5. 12) 

tdlrsp_nr_007.tc 

tdlrsp_nr_007.ex 

tdlrsp nr 008. m 

Test: Beam 2 in lock (line 3 of table 5.12) 

tdlrsp_nr_008.tc 

tdlrsp_nr_008.ex 

tdlrsp nr 009. m 

Test: Beam 3 in lock (line 4 of table 5.12) 

tdlrsp_nr_009.tc 

tdlrsp_nr_009.ex 

tdlrsp nr OlO.m 

Test: Beam 4 in lock (line 5 of table 5. 12) 

tdlrspnrOlO.tc 

tdlrsp nr 010. ex 

tdlrsp nr Oll.m 

Test: Beams 1 & 2 in lock (line 6 of table 5.12) 

tdlrsp nr 01 l.tc 

tdlrsp nr 01 l.ex 

tdlrsp nr 012. m 

Test: Beams 1 & 3 in lock (line 7 of table 5.12) 

tdlrsp_nr_012.tc 

tdlrsp nr 01 2. ex 

tdlrsp nr 013.m 

Test: Beams 1 & 4 in lock (line 8 of table 5.12) 

tdlrsp_nr_013.tc 

tdlrsp_nr_013.ex 

tdlrsp nr 014.m 

Test: Beams 2 & 3 in lock (line 9 of table 5.12) 

tdlrsp_nr_014.tc 

tdlrsp nr 01 4. ex 

tdlrsp nr 015.m 

Test: Beams 2 & 4 in lock (line 10 of table 5.12) 

tdlrsp_nr_015.tc 

tdlrsp_nr_015.ex 

tdlrsp nr 016.m 

Test: Beams 3 & 4 in lock (line 1 1 of table 5.12) 

tdlrsp_nr_016.tc 

tdlrsp nr 01 6. ex 

tdlrsp nr 017.m 

Test: Beams 1, 2, & 3 in lock (line 12 of table 5.12) 

tdlrsp_nr_017.tc 

tdlrsp_nr_017.ex 

tdlrsp nr 018.m 

Test: Beams 1, 2, & 4 in lock (line 13 of table 5.12) 

tdlrsp_nr_018.tc 

tdlrsp nr 01 8. ex 

tdlrsp nr 019.m 

Test: Beams 1, 3, & 4 in lock (line 14 of table 5.12) 

tdlrsp_nr_019.tc 

tdlrsp nr 01 9. ex 

tdlrsp_nr_020.m 

Test: Beams 2, 3, & 4 in lock (line 15 of table 5.12) 

tdlrsp_nr_020.tc 

tdlrsp nr 020. ex 

tdlrsp nr 021.m 

Test: ALL Beams in lock (line 16 of table 5.12) 

tdlrsp_nr_021.tc 

tdlrsp nr 02 l.ex 

tdlrsp_ro_022.m 

Test FRAMEBEAMUNLOCKED out of UPPER 
bound 

tdlrsp_ro_022.tc 

tdlrsp_ro_022.ex 

tdlrsp_ro_023.m 

Test FRAME BEAM UNLOCKED out of LOWER 
bound 

tdlrsp_ro_023.tc 

tdlrsp_ro_023.ex 

tdlrsp_ro_024.m 

Test FRAMECOUNTER out of UPPER bound 

tdlrsp_ro_024.tc 

tdlrsp ro 024. ex 

tdlrsp_ro_025.m 

Test FRAME COUNTER out of LOWER bound 

tdlrsp_ro_025.tc 

tdlrsp_ro_025.ex 

tdlrsp_ro_026.m 

Test TDLR STATE INVALID value 

tdlrsp_ro_026.tc 

tdlrsp_ro_026.ex 

tdlrsp_ro_027.m 

Test TDLR COUNTER out of LOWER bound 

tdlrsp_ro_027.tc 

tdlrsp_ro_027.ex 

tdlrsp_ro_028.m 

Test TDLR COUNTER out of UPPER bound 

tdlrsp_ro_028.tc 

tdlrsp_ro_028.ex 
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A.3.7 GP Functional Unit Test Cases 


Table 9 is a listing of all requirements-based test cases for the GP functional unit. All test 
cases manipulate the variables: 


AESWITCH 

GPPHASE 

AETEMP 

GPVELOCITY 

ARALTITUDE 

GROTATION 

AACCELERATION 

KALT 

CHUTERELEASED 

KMATRIX 

CL 

RESWITCH 

CONTOURCROS SED 

TDLRVELOCITY 

FRAMECOUNTER 

TDSSTATUS 

GPALTITUDE 

TDSENSED 

GPATTITUDE 



GP robustness test cases # 60 - 65 are supposed to provide out-of-bounds testing for 
GP_VELOCITY(1...3,0) which is both computed and then used in GP. The computation for this 
is impossible to reverse engineer to get starting values. Currently the best way to do this is to 
make other time histories (specifically GP_VELOCITY(1...3,2) ) out of bounds, thereby forcing 
GP_VELOCITY(1...3,0) out of bounds. 
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Table A.9: Test cases for GP functional unit. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

gptc. 1 

Initial GP Frame with All valid inputs. Tests Equivalence Classes: 
A ACCELERATION. 1 GPALTITUDE. 1 

GPATTITUDE. 1 GP VELOCITY. 1 

G ROTATION. 6 TDLR VELOCITY. 1 

GROTATION.8 GROTATION.IO 

gpnrOO 1 .tc 

gpnrOO 1 .ex 

gpjc.2 

Transition Frame, Frame 246 with all valid inputs Tests Equivalence 
Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION. 6 TDLR VELOCITY. 1 

G ROTATIONS G ROTATION. 9 

gp nr 002.tc 

gp_nr_002.ex 

gpjc.3 

FRAME = 25 1 with CHUTE RELEASED set to 1 . All valid data 
tested. Also tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

GROTATION.6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATION. 9 

gp nr 003.tc 

gp_nr_003.ex 

gpjc.4 

FRAME = 252 with CHUTE RELEASED = 1 where GP PHASE 
goes to 3. All valid data tested. Also tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION. 6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATION. 9 

gp nr 004.tc 

gp_ nr _004.ex 

gpjc.5 

FRAME 950 when CONTOUR CROSSED will be set to 1 by the end 
of the frame. All valid data tested. Also tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

GROTATION.5 TDLR VELOCITY. 1 

GROTATION.6 

gp_nr_005.tc 

gp_nr_005.ex 

gpjc.6 

FRAME 951 with CONTOUR CROSSED = 1. Tests all valid data 
and equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION. 5 TDLR VELOCITY. 1 

GROTATION.6 

gp_nr_006.tc 

gp_nr_006.ex 

gpjc.7 

FRAME = 2073 when CL = 2. Tests valid data and Equivalence 
Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION. 5 TDLR VELOCITY. 1 

G ROTATION. 6 

gp_nr_007.tc 

gp_nr_007.ex 

gpjc.8 

FRAME = 2078 where CL = 2 and GP PHASE changes to 4. Tests 
valid data and Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION. 5 TDLR VELOCITY. 1 

G ROTATION. 6 

gp nr 008.tc 

gp_nr_008.ex 

gPjc-9 

FRAME = 2073 where CL = goes to 2. Tests valid data & 
Equivalence Classes: 

A ACCELERATION. 1 GPALTITUDE.4 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.5 TDLR VELOCITY. 1 

gp_nr_053.tc 

gp_nr_053.ex 
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FRAME = 2078 CL = 2, GP PHASE changes to 5 (TD SENSED = 1, 
GP PHASE = 2, and engines are not HOT, Chute is attached) Tests 
valid data and Equivalence Classes: 

A ACCELERATION. 1 GPALTITUDE.3 

GPATTITUDE. 1 GP VELOCITY. 1 

GROTATION.5 TDLR VELOCITY. 1 

FRAME = 2078 CL = 2, GP PHASE changes to 5 (ALT <= 

DROP HEIGHT, TDSSTATUS = failed, GP PHASE = 3). Tests 
valid data and Equivalence Classes: 

A ACCELERATION. 1 GPALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.5 TDLR VELOCITY. 1 

FRAME = 2078 CL = 2, GP PHASE changes to 5 (Chute released, 
Engines Hot, Touchdown sensed). Tests valid data and Equivalence 
Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.5 TDLR VELOCITY. 1 

FRAME = 2078 CL = 2, GP PHASE changes to 5 (Chute released, 
Engines off, Touchdown sensed). Tests valid data & Equivalence 
Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.5 TDLR VELOCITY. 1 

FRAME = 2078 CL = 2, GP PHASE changes to 5 (Chute released, 
Engines off, TDS STATUS = failed) Tests valid data and 
Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.5 TDLR VELOCITY. 1 

Based on FRAME = 951 GPALT2 is < 0. (after rotation) Tests 
Equivalence Classes: GP ALTITUDE.3 

Based on FRAME = 95 1 GPALT2 is > 2000. (after rotation) Tests 

Equivalence Classes: GP ALTITUDE. 2 

Based on FRAME = 951 A_ACCELERATION( 1 ,0) < -20. Tests 

Equivalence Classes: AACCELERATION.3 

Based on FRAME = 951 A_ACCELERATION( 1 ,0) > 5. Tests 

Equivalence Classes: A ACCELERATIONS 

Based on FRAME = 951 A_ACCELERATION(2,0) < -20. Tests 

Equivalence Classes: A ACCELERATION.3 

Based on FRAME = 951 A_ACCELERATION(2,0) > 5. Tests 

Equivalence Classes: A ACCELERATION.2 

Based on FRAME = 951 A_ACCELERATION(3,0) < -20. Tests 

Equivalence Classes: A ACCELERATION.3 

Based on FRAME = 951 A_ACCELERATION(3,0) > 5. Tests 

Equivalence Classes: A ACCELERATION.2 

Based on FRAME = 951 A_ACCELERATION(l,l) < -20. Tests 

Equivalence Classes: A ACCELERATION.3 

Based on FRAME = 951 A_ACCELERATION(l,l) > 5. Tests 

Equivalence Classes: A ACCELERATION.2 

Based on FRAME = 951 A_ACCELERATION(2,l) < -20. Tests 

Equivalence Classes: A ACCELERATION.3 

Based on FRAME = 951 A_ACCELERATION(2,l) > 5. Tests 

Equivalence Classes: A ACCELERATION.2 

Based on FRAME = 951 A_ACCELERATION(3,l) < -20. Tests 

Equivalence Classes: A ACCELERATION.3 

Based on FRAME = 951 A_ACCELERATION(3,l) > 5. Tests 

Equivalence Classes: A ACCELERATION.2 

Based on FRAME = 95 1 A_ACCELERATION( 1 ,2) < -20. Tests 

Equivalence Classes: A ACCELERATION.3 

Based on FRAME = 951 A_ACCELERATION(l,2) < 5. Tests 

Equivalence Classes: A ACCELERATION.2 


gp_nr_102.tc 


gp_nr_102.ex 


gp_nr_103.tc 


gp _nr_104.tc 


gp_nr_105.tc 


gp_nr_106.tc 


gp_ro_009.tc 


gproOlO.tc 


gp_ro_0 1 1 .tc 


gp_ro_012.tc 


gp_ro_013.tc 


gp_ro_014.tc 


gp_ro_015.tc 


gp_ro_0 1 6.tc 


gp_ro_017.tc 


gp_ro_018.tc 


gp_ro_019.tc 


gp_ro_020.tc 


gp_ro_021.tc 


gp_ro_022.tc 


gp_ro_023.tc 


gp_ro_024.tc 


gp_nr_103.ex 


gp_nr_104.ex 


gp_nr_105.ex 


gp_nr_106.ex 


gp_ro_009.ex 


gproOlO.ex 
gp_ro_0 1 1 .ex 


gp_ro_012.ex 


gp_ro_013.ex 


gp_ro_014.ex 

gp_ro_015.ex 


gp_ro_016.ex 


gp_ro_017.ex 


gp_ro_018.ex 


gp_ro_019.ex 

gp_ro_020.ex 


gp_ro_021.ex 


gp_ro_022.ex 


gp_ro_023.ex 


gp_ro_024.ex 
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Based on FRAME = 95 1 q2 = G_ROTATION(2, 2) < -1 (as used by gp_ro_079.tc 
the program in GP ROTATION) Tests Equivalence Classes: 

GROTATION. 12 

Based on FRAME = 951 r2 = G_ROTATION(3, 2) < -1 (as used by gp_ro_080.tc 
the program in GP ROTATION) Tests Equivalence Classes: 

GROTATION. 12 

Based on FRAME = 951 pO = G ROTATION! 1 , 2) > 1 (as used by gp_ro_08 1 .tc 
the program in GP ROTATION) Tests Equivalence Classes: 

G_ROTATION.ll 

Based on FRAME = 951 q2 = G_ROTATION(2,2) > 1 (as used by gp_ro_082.tc 
the program in GP ROTATION) Tests Equivalence Classes: 

G_ROTATION.ll 

Based on FRAME = 951 r2 = G_ROTATION(3, 2) > 1 (as used by gp_ro_083.tc 
the program in GP ROTATION) Tests Equivalence Classes: 

G_ROTATION.ll 

FRAME = 951 TDLVELO (1) < -100 Tests Equivalence Classes: gp_ro_084.tc 

TDLR VELOCITY.3 

FRAME = 95 1 TDLVELO (1) > 100 Tests Equivalence Classes: gp_ro_085.tc 

TDLR VELOCITY.2 

FRAME = 951 TDLVELO (2) < -100 Tests Equivalence Classes: gp_ro_086.tc 

TDLR VELOCITY.3 

FRAME = 951 TDLVELO (2) > 100 Tests Equivalence Classes: gp_ro_087.tc 

TDLR VELOCITY.2 

FRAME = 951 TDLVELO (3) < -100 Tests Equivalence Classes: gp_ro_088.tc 

TDLR VELOCITY.3 

FRAME = 951 TDLVELO (3) > 100 Tests Equivalence Classes: gp_ro_089.tc 

TDLR VELOCITY.2 

FRAME = 951 TDLVEL1 (1) < -100 Tests Equivalence Classes: gp_ro_090.tc 

TDLR VELOCITY.3 

FRAME = 951 TDLVEL1 (1) > 100 Tests Equivalence Classes: gp_ro_091.tc 

TDLR VELOCITY.2 

FRAME = 951 TDLVEL1 (2) < -100 Tests Equivalence Classes: gp_ro_092.tc 

TDLR VELOCITY.3 

FRAME = 951 TDLVEL1 (2) > 100 Tests Equivalence Classes: gp_ro_093.tc 

TDLR VELOCITY.2 

FRAME = 951 TDLVEL1 (3) < -100 Tests Equivalence Classes: gp_ro_094.tc 

TDLR VELOCITY.3 

FRAME = 95 1 TDLVEL1 (3) > 100 Tests Equivalence Classes: gp_ro_095.tc 

TDLR VELOCITY.2 

FRAME = 951 TDLVEL2 (1) < -100 Tests Equivalence Classes: gp_ro_096.tc 

TDLR VELOCITY.3 

FRAME = 951 TDLVEL2 (1) > 100 Tests Equivalence Classes: gp_ro_097.tc 

TDLR VELOCITY.2 

FRAME = 951 TDLVEL2 (2) < -100 Tests Equivalence Classes: gp_ro_098.tc 

TDLR VELOCITY.3 

FRAME = 951 TDLVEL2 (2) > 100 Tests Equivalence Classes: gp_ro_099.tc 

TDLR VELOCITY.2 

FRAME = 95 1 TDLVEL2 (3) < -100 Tests Equivalence Classes: gp ro lOO.tc 

TDLR VELOCITY.3 

FRAME = 951 TDLVEL2 (3) > 100 Tests Equivalence Classes: gp ro lOl.tc 

TDLR VELOCITY.2 

This is a special robustness test that tests the valid inputs not gp_ro_107.tc 

accounted for in the Spec table 5.10 In this test GP PHASE = 1 and 
alt > ENGINES ON ALTITUDE 
Tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE.2 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION. 1 0 TDLR VELOCITY. 1 

G ROTATION. 6 


gp_ro_079.ex 


gp_ro_080.ex 


gp_ro_081.ex 


gp_ro_082.ex 


gp_ro_083.ex 


gp_ro_084.ex 


gp_ro_085.ex 


gp_ro_086.ex 


gp_ro_087.ex 


gp_ro_088.ex 


gp_ro_089.ex 


gp_ro_090.ex 


gp_ro_091.ex 


gp_ro_092.ex 


gp_ro_093.ex 


gp_ro_094.ex 


gp_ro_095.ex 


gp_ro_096.ex 


gp_ro_097.ex 


gp_ro_098.ex 


gp_ro_099.ex 


gprolOO.ex 


gprolOl.ex 


gp_ro_107.ex 
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gptc.108 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5. 10 In this test GP PHASE = 2, 
AETEMP = 0, CHUTE RELEASED = 1 
Tests Equivalence Classes: 

A ACCELERATION. 1 GPALTITUDE.2 

GPATTITUDE. 1 GP VELOCITY. 1 

GROTATION.6 TDLR VELOCITY. 1 

GROTATION.8 G ROTATIONS 

gp_ro_108.tc 

gp_ro_108.ex 

gptc.109 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5. 10 In this test GP PHASE = 2, 
AE TEMP = 1, CHUTE RELEASED = 1 
Tests Equivalence Classes: 

A ACCELERATION. 1 GPALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATION. 9 

gp_ro_109.tc 

gp_ro_109.ex 

gptc.110 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5.10 In this test GP PHASE = 2, 
AE TEMP = 2, CHUTE RELEASED = 0 
Tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATION. 9 

gprol lO.tc 

gprol lO.ex 

gp_tc.ll 1 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5.10 In this test GP PHASE = 3, 
AE TEMP = 2, CHUTE RELEASED = 1, TD SENSED=0 alt > 
DROP HEIGHT, TDS STATUS = healthy, EQ <= 

MAX_N ORMAL VELOCITY . 

Tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATION. 9 

gprol 1 l.tc 

gprol 1 1 .ex 

gptc.l 12 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5.10 In this test GP PHASE = 3, 
AE TEMP = 2, CHUTE RELEASED = 1, TD SENSED=0 alt <= 
DROP HEIGHT, TDS STATUS = failed, EQ <= 
MAXNORMALVELOCITY 
Tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATIONS 

gprol 12.tc 

gprol 12.ex 

gptc.l 13 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5.10 In this test GP PHASE = 3, 
AE TEMP = 2, CHUTE RELEASED = 1, TD SENSED=0 alt <= 
DROP HEIGHT, TDS STATUS = healthy, EQ > 
MAXNORMALVELOCITY 
Tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATION. 9 

gprol 13.tc 

gprol 13. ex 

gptc.l 14 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5.10 In this test GP PHASE = 3, 
AE TEMP = 2, CHUTE RELEASED = 1 , TD SENSED=0 alt > 
DROP HEIGHT, TDS STATUS = failed, EQ <= 
MAXNORMALVELOCITY 
Tests Equivalence Classes: 

A ACCELERATION. 1 GP ALTITUDE. 1 

GP ATTITUDE. 1 GP VELOCITY. 1 

G ROTATION.6 TDLR VELOCITY. 1 

G ROTATION.8 G ROTATION. 9 

gprol 14.tc 

gprol 14.ex 
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gptc.l 15 

FRAME COUNTER = 0, which is out-of-bounds, making 
FRAMEENGINES IGNITED out-of-bounds. FRAMECOUNTER 
is an input from the simulator, so this is an unusual case (an invalid 
case), but the only way it can be tested 
Tests Equivalence Classes: FRAMEENGINE SIGNITED . 3 

gp_ro_l 15.tc 

gprol 15.ex 

gptc.l 16 

FRAME COUNTER = -32768, which is out-of-bounds, making 
FRAME ENGINES IGNITED out-of-bounds. FRAME COUNTER 
is an input from the simulator, so this is an unusual case (an invalid 
case), but the only way it can be tested 
Tests Equivalence Classes: FRAMEENGINESIGNITED.2 

gprol 16.tc 

gprol 16.ex 

gptc.l 17 

This is a special robustness test that tests the valid inputs not 
accounted for in the Spec table 5.9 In this test AE SWITCFI = on, 
GP ALTITUDE > DROP HEIGHT, 

SQRT(2*GRAVITY*GP ALTITUDE) + GP VELOCITY(x) <= 
MAX NORMAL VELOCITY 
Tests Equivalence Classes: 

A ACCELERATION. 1 GPALTITUDE. 1 

GPATTITUDE. 1 GP VELOCITY. 1 

GROTATION.5 TDLR VELOCITY. 1 

GROTATION.6 

gp_ro_l 17.tc 

gprol 17.ex 
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Tables 10a and 10b below provide more information about the robustness test cases that test 
table 5.10 of the GCS Specification. These table cover GPPHASE transitions resulting from 
variable combinations that are possible but not specified. The information is divided into two 
tables to avoid confusion resulting from the heterogeneous mix of variables used in determining 
the value of GP PHASE as given in Table 5.10 of the GCS Specification. Table A.IOa covers 
transitions for GP PHASE equal 1 and 2; while Table A. 10b covers transitions for GP PHASE 
equal 3 


Table A.IOa: Valid data not accounted for in Table 5.10 of the GCS specification 


In] 

put 

Output 

Test Case 

GP_ 

PHASE 

TDSENSED 

AE_ 

TEMP 

CHUTE_ 

RELEASED 

GPALTITUDE 

GP_ 

PHASE 

Names 

1 

Not Sensed 

Cold 

Not Released 

> ENGINES_ON_ 
ALTITUDE 

1 

GPRO107.TC 

2 

Not Sensed 

Cold 

Released 

< ENGINE S_ON_ 
ALTITUDE 

2 

GPRO108.TC 

2 

Not Sensed 

Warm 

Released 

< ENGINE S_ON_ 
ALTITUDE 

2 

GPRO109.TC 

2 

Not Sensed 

Hot 

Not Released 

< ENGINES_ON_ 
ALTITUDE 

2 

GPROl 10.TC 


Table A.IOa: Valid data not accounted for in Table 5.10 (Part B) ofthe GCS specification 


Input 

Output 

Test Case 

GP 

PHASE 

TD 

SENSED 

AE 

TEMP 

CHUTE 

RELEASED 

Altitude 

J2 • Gravity • GP _ ALTITUDE 
+ GP_ VELOCITY(x) 

TDS_ 

STATUS 

GP 

PHASE 

Names 

3 

Not 

Sensed 

Hot 

Released 

>DROP_ 

HEIGHT 

< MAX N ORMAL_ 
VELOCITY 

healthy 

3 

GP RO lll.T 
C 

3 

Not 

Sensed 

Hot 

Released 

<DROP_ 

HEIGHT 

< MAX N ORMAL_ 
VELOCITY 

failed 

3 

GP RO 1 12. T 
C 

3 

Not 

Sensed 

Hot 

Released 

<DROP_ 

HEIGHT 

>MAX_N ORMAL_ 
VELOCITY 

healthy 

3 

GP RO 1 13.T 
C 

3 

Not 

Sensed 

Hot 

Released 

>DROP_ 

HEIGHT 

< MAX N ORMAL_ 
VELOCITY 

failed 

3 

GP RO 1 14. T 

C 
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A.3.8 AECLP Functional Unit Test Cases 


Table A. 1 1 gives a listing of all requirements-based test cases for the AECLP functional unit. 
Table A. 12 gives additional AETEMP transitions for robustness test cases that test Table 5.1 of 
the GCS Specification. It covers conditions not given in Table 5.1 of the GCS Specification. All 
test cases manipulate the variables: 


AACCELERATION 

GPROTATION 

AESWITCH 

GPVELOCITY 

AETEMP 

INTERN ALCMD 

CHUTERELEASED 

PEINTEGRAL 

CL 

TEDROP 

CONTOURCROSSED 

TEINTEGRAL 

FRAMECOUNTER 

TELIMIT 

FRAMEENGINESIGNITED 

VELOCITYERROR 

GPALTITUDE 

YEINTEGRAL 

GPATTITUDE 
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Table A. 1 1 : Test cases for AECLP functional unit. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

aeclptc.l 

Initial AECLP Frame. Tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATIONS 

aeclpnrOO 1 .tc 

aeclpnrOO 1 .ex 

aeclp_tc.2 

Frame 2, tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YE INTEGRAL. 1 TE INTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATIONS 

aeclp_nr_002.tc 

ae c lp_nr_002.ex 

aeclp_tc.3 

Frame 251, tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATIONS 

aeclp_nr_003.tc 

aec lp_nr_003 .ex 

aeclp_tc.4 

Frame 252, tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YE INTEGRAL. 1 TE INTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATION. 8 

GROTATION.6 

aeclp_nr_004.tc 

a eelp_nr_004.ex 

aeclp_tc.5 

Frame 950, tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 GROTATION.IO 

GROTATION.5 

aeclp_nr_005.tc 

aeclp_nr_005.ex 

aeclp_tc.6 

Frame 95 1 , tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT.2 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATION.IO 

GROTATION.5 

aeclp_nr_006.tc 

ae c lp_nr_006.ex 

aeclp_tc.7 

Frame 2077 tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT.2 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATION.IO 

GROTATION.5 

aeclp_nr_007.tc 

ae c lp_nr_007.ex 

aeclp_tc.8 

Frame 2078 tests valid inputs and Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT.2 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATIONS 

aeclp_nr_008.tc 

ae c lp_nr_008.ex 
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aeclp_tc.9 


Frame 2083 tests valid inputs and Equivalence Classes: aeclp_nr_009.tc aeclp_nr_009.ex 

A ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT.2 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 

aeclptc.10 Frame 250 tests valid inputs and Equivalence Classes: aeclpnrOlO.tc aeclpnrOlO.ex 

A ACCELERATION.! PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G ROTATION. 8 

GROTATION.6 

aeclptc. 1 1 Frame 949 tests valid inputs and Equivalence Classes: aeclpnrO 1 1 .tc aeclpnrO 1 1 .ex 

A_ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G_ROTATION.5 

aeclptc.12 Frame 955 tests valid inputs and Equivalence Classes: aeclp_nr_012.tc aeclp_nr_012.ex 

A_ACCELERATION. 1 PE INTEGRAL. 1 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT.2 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERROR. 1 G_ROTATION.5 

aeclptc.13 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_013.tc aeclp_ro_013.ex 

GPALTITUDE.4 

aeclptc.14 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_014.tc aeclp_ro_014.ex 

GPALTITUDE.3 

aeclptc.15 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_015.tc aeclp_ro_015.ex 

GPATTITUDE.3 

aeclptc.16 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclproO 1 6.tc aeclp_ro_016.ex 

GPATTITUDE.2 

aeclptc.17 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_017.tc aeclp_ro_017.ex 

GP ROTATIONS 

aeclp tc.18 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_018.tc aeclp_ro_018.ex 

GP ROTATIONS 

aeclp tc.19 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_019.tc aeclp_ro_019.ex 

GP ROTATIONS 

aeclp_tc.20 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_020.tc aeclp_ro_020.ex 

GP ROTATIONS 

aeclp_tc.21 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_02 1 .tc aeclp_ro_021.ex 

GP VELOCITY.3 

aeclp_tc.22 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_022.tc aeclp_ro_022.ex 

GP VELOCITY.2 

aeclp_tc.23 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_023.tc aeclp_ro_023.ex 

GP VELOCITY.3 

aeclp_tc.24 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_024.tc aeclp_ro_024.ex 

GP VELOCITY.2 

aeclp_tc.25 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_025.tc aeclp_ro_025.ex 

GP VELOCITY.3 

aeclp_tc.26 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_026.tc aeclp_ro_026.ex 

GP VELOCITY.2 

aeclp_tc.27 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_027.tc aeclp_ro_027.ex 

PE INTEGRAL. 3 

aeclp_tc.28 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_028.tc aeclp_ro_028.ex 

PE INTEGRALS 

aeclp_tc.29 Tests Frame 955 with all valid inputs and Equivalence Classes: aeclp_ro_029.tc aeclp_ro_029.ex 

TE INTEGRALS 
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aeclp_tc.30 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
TEINTEGRAL.2 TELIMIT.3 

aec lp_ r °_030.tc 

aeclp_ ro _030.ex 

aeclp_tc.31 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
TELIMIT.5 

aeclp_ r °_03 1 .tc 

aeclp_ro_03 1 .ex 

aeclp_tc.32 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
TELIMIT.4 

aeclp_ro_032.tc 

aeclp_ r °_032.ex 

aeclp_tc.33 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
VEL0CITYERR0R.3 

aeclp_ro_033.tc 

aeclp_ ro _033.ex 

a eclp_t c .34 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
VEL0CITYERR0R.3 TELIMIT.3 

aeclp_ro_034.tc 

aeclp_ ro _034.ex 

aeclp_tc.35 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
YEINTEGRAL.3 

aeclp_ro_035.tc 

aeclp_ r °_035.ex 

a eclp_te.36 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
YEINTEGRAL.2 

aeclp_ro_036.tc 

aeclp_ ro _036.ex 

aeclp_tc.37 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
AACCELERATI0N.3 

aeclp_ro_037.tc 

aeclp_ ro _037.ex 

a eclp_te.38 

Tests Frame 955 with all valid inputs and Equivalence Classes: 
AACCELERATI0N.2 

aeclp_ro_038.tc 

aeclp_ ro _038.ex 

aeclp_tc.39 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE.2 

VELOCITY ERRORS 

aeclp_ro_039.tc 

aeclp_ ro _039.ex 

aeclp_tc.40 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE.2 

VELOCITY ERRORS 

aeclp_ro_040.tc 

aeclp_ ro _040.ex 

a eclp_te.41 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE. 1 

VELOCITY ERRORS 

aeclp_ro_04 1 .tc 

aeclp_ro_04 1 .ex 

a eclp_t c .42 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD.l GPALTITUDE.2 

VELOCITY ERRORS 

aeclp_ r °_042.tc 

aeclp_ro_042.ex 

a eclp_te.43 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD. 1 GPALTITUDE. 1 

VELOCITY ERRORS 

aeclp_ro_043.tc 

a eclp_ ro _043 .ex 
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aeclptc.44 

This robustness case tests a condition not listed in table 5. 1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD. 1 GPALTITUDE.2 

VELOCITY ERRORS 

a eclp_ r °_044.tc 

a eclp_ r °_044.ex 

a eclp_te.45 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD. 1 GPALTITUDE.2 

VELOCITY ERRORS 

a eclp_ro_045.tc 

a eclp_ r °_045 .ex 

a eclp_t c .46 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YEINTEGRAL. 1 TEINTEGRAL. 1 

TELIMIT. 1 INTERNAL.CMD. 1 

AECMD. 1 GPALTITUDE. 1 

VELOCITY ERRORS 

a eclp_ro_046.tc 

a eclp_ro_046.ex 

aeclp_tc.47 

This robustness case tests a condition not listed in table 5.1 of the 
Spec. The combination of these values may cause invalid state 
transitions. Also Tests Equivalence Classes: 

A ACCELERATIONS PE INTEGRALS 

YE INTEGRALS TE INTEGRALS 

TE LIMITS INTERNAL.CMD. 1 

AE CMD.l GP ALTITUDE.2 

VELOCITY ERRORS 

a eclp_ro_047.tc 

a eclp_ r °_047.ex 

a eclp_t c .48 

This case uses all valid inputs, but the value for G ROTATION(2) has 
been computed to give a specific result in INTERNAL CMD. 
INTERNAL CMD( 1) = -.701 (which is out of bounds) Tests 
Equivalence Classes: 

INTERN AL.CMD.3 

a eclp_ro_048.tc 

a eclp_ r °_048.ex 

a eclp_tc.49 

This case uses all valid inputs, but the value for G ROTATION(2) 
has been computed to give a specific result in INTERNAL CMD. 
INTERNAL CMD(l) = 1.701 (which is out of bounds) Tests 
Equivalence Classes: 

INTERN AL.CMD.2 

a eclp_ro_049.tc 

a eclp_ r °_049.ex 

a eclp_te.50 

This case uses all valid inputs, but the value for G ROTATION(3) has 
been computed to give a specific result in INTERNAL CMD. 
INTERNAL CMD(2) = -.701 (which is out of bounds) Tests 
Equivalence Classes: 

INTERN AL.CMD.3 

a eclp_ro_050.tc 

a eclp_ ro _050.ex 

aeclp_tc.51 

This case uses all valid inputs, but the value for G ROTATION(3) has 
been computed to give a specific result in INTERNAL CMD. 
INTERNAL CMD(2) = 1.701 (which is out of bounds) Tests 
Equivalence Classes: 

INTERN AL.CMD.2 

a eclp_ro_05 1 .tc 

a eclp_ro_05 1 .ex 

a eclp_t c .52 

This c a se uses a ll vdid inputs, but the v a lue for TE_INIT h a s been 
computed to give a specific result in INTERN ALCMD. 
INTERNAL_CMD(3) = -.701 (which is out of bounds) Tests 
Equivulence Casses: 

INTERN AL.CMD.3 

a eclp_ro_052.tc 

a eclp_ r °_052.ex 

aeclp_tc.53 

This c a se uses a ll v a lid inputs, but the v a lue for TE INIT h a s been 
computed to give out of bound results in INTERNAL CMD. 
INTERN AL_CMD(3) = 1.701 Tests Equivulence Casses: 
INTERNAL.CMD.2 

a eclp_ro_053.tc 

a eclp_ro_053.ex 
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aeclp_tc.54 

AE SWITCH is still off at end of frame, giving AE CMD = 0 
FRAME ENGINES IGNITED > 1 All valid inputs. Tests 
Equivalence Classes: 

A ACCELERATION. 1 PE INTEGRAL. 1 

YE INTEGRAL. 1 TE INTEGRAL. 1 

TE LIMIT. 1 INTERNAL.CMD. 1 

AE CMD. 1 GP ALTITUDE. 1 

VELOCITY ERROR. 1 

aeclp_ n r_054.tc 

aec lp_n r _054.ex 

aeclp_tc.55 

This tests INTERNAL CMD >1.0 Tests Equivalence Classes: 
A ACCELERATION. 1 PE INTEGRAL. 1 

YE INTEGRAL. 1 TE INTEGRAL. 1 

TE LIMIT. 1 INTERNAL.CMD. 1 

AE CMD. 1 GP ALTITUDE. 1 

VELOCITY ERROR. 1 

aeclp_ n r_055.tc 

aec lp_n r _055.ex 

aeclp_tc.56 

Tests Equivalence Classes: FRAMEENGINESIGNITED.2 

aeclp_ro_056.tc 

aec lp_ r °_056.ex 

aeclp_tc.57 

Tests Equivalence Classes: FRAMEENGINESIGNITED.3 

aeclp_ r °_057.tc 

aeclp_ro_057.ex 
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Table A. 12: AE TEMP transitions not covered in Table 5.1 of GCS Specification. 


Input 

Output 

Test Case 

AEJTEMP 

GP ALTITUDE 

(FRAMECOUNTER - 

FRAME ENGINES IGNITED) 

* 

DELTAT 

AE TEMP 

Names 

COLD 

> ENGINESONALTITUDE 

< FULLUPTIME 

COLD 

AECLPR0 39.TC 

COLD 

> ENGINES ON ALTITUDE 

> FULL UP TIME 

COLD 

AECLPRO40.TC 

COLD 

< ENGINES ON ALTITUDE 

> FULL UP TIME 

COLD 

AECLPR04 1 .TC 

WARM 

> ENGINES ON ALTITUDE 

< FULL UP TIME 

WARM 

AECLPR0 42.TC 

WARM 

< ENGINES ON ALTITUDE 

< FULL UP TIME 

WARM 

AECLPR0 43 .TC 

WARM 

> ENGINES ON ALTITUDE 

> FULL UP TIME 

WARM 

AECLPR0 44.TC 

HOT 

> ENGINES ON ALTITUDE 

< FULL UP TIME 

HOT 

AECLPR0 45 .TC 

HOT 

< ENGINES ON ALTITUDE 

< FULL UP TIME 

HOT 

AECLPR0 46.TC 

HOT 

> ENGINES ON ALTITUDE 

> FULL UP TIME 

HOT 

AECLPR0 47.TC 
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A.3.9 RECLP Functional Unit Test Cases 


The requirements-based test cases for the RECLP functional unit are given in Table A. 13. 
This test suite involves three test variables, RE SWITCH, GROTATION, and THETA. 
RE SWITCH is 1 for all test cases the values for the other two variables are given in the 
Description column. The majority of the testing for this functional unit involves determination of 
RECMD based on the values of G ROTATION and THETA. RECMD is determined by 
plotting G ROTATION and THETA on Figure A.5.2 of the GCS Specification. 


Table A. 13: Test cases for RECLP functional unit. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

reclptc.l 

This case tests 

THETA = 0.002569999999999999, 

G ROTATION = 0.00157 
RECMD = 1 . 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.2 

reclpnrOO 1 .tc 

reclp m*_00 1 .ex 

reclp_tc.2 

This case tests 

THETA = -0.002569999999999999, 

G ROTATION = 0.00157 
RE CMD = 1 . 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.3 

rec lp_nr_002.tc 

reclp_nr_002.ex 

reclp_tc.3 

This case tests 

THETA = -0.002569999999999999, 

G ROTATION = -0.00157 
RE CMD = 1 . 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.3 

reclp_nr_003.tc 

reclp_nr_003.ex 

reclp_tc.4 

This case tests 

THETA = 0.002569999999999999, 

G ROTATION = -0.00157 
& RE CMD = 1 . 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.4 

reclp_nr_004.tc 

reclp_nr_004.ex 

reclp_tc.5 

This case tests 
THETA = 0.00478, 

G ROTATION = -0.00157 
RE CMD = 1 . 

Tests valid inputs and Equivalence Classes: 
G ROTATION. 1 
THETA. 5 

rec lp_nr_005.tc 

reclp_nr_005.ex 

reclp_tc.6 

This case tests 
THETA = -0.00478, 

G ROTATION = -0.00157 
RE_CMD should be 2. 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.2 

reclp_nr_006.tc 

reclp_nr_006.ex 
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reclp_tc.7 

This case tests 
THETA = -0.00478, 

G ROTATION = 0.00157 
RE_CMD should be 1 . 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.2 

rec lp_nr_007.tc 

reclp_nr_007.ex 

reclp_tc.8 

This case tests 
THETA = 0.00478, 

G ROTATION = 0.00157 
RE CMD should be 2. 

Tests valid inputs and Equivalence Classes: 
G ROTATION. 1 
THETA. 5 

reclp_nr_008.tc 

reclp_nr_008.ex 

reclp_tc.9 

This case tests 
THETA = 0.00634, 

G ROTATION = 0.00157 
RE CMD should be 7. 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.6 

rec lp_nr_009.tc 

reclp_nr_009.ex 

reelpte.lO 

This case tests 
THETA = -0.00634, 

G ROTATION = 0.00157 
RE CMD should be 6. 

Tests valid inputs and Equivalence Classes: 
G ROTATION. 1 
THETA. 1 

reclpnrOlO.tc 

reclpnrOlO.ex 

reclptc. 1 1 

This case tests 
THETA = -0.00634, 

G ROTATION = -0.00157 
RE CMD should be 6. 

Tests valid inputs and Equivalence Classes: 
G ROTATION. 1 
THETA. 1 

reclpnrOl l.tc 

reclpnrOll.ex 

reclptc.12 

This case tests 
THETA = 0.00634, 

G ROTATION = -0.00157 
RE CMD should be 7. 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.6 

rec lp_nr_012.tc 

reclp_nr_012.ex 

reelp te. 13 

This case tests 

THETA = 0.002569999999999999, 

G ROTATION = 0.00828 
RE CMD should be 7. 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.4 

rec lp_nr_013.tc 

reclp_nr_013.ex 

reclptc.14 

This case tests 

THETA = -0.002569999999999999, 

G ROTATION = 0.00828 

RE CMD should be 1 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.3 

reclp_nr_014.tc 

reclp_nr_014.ex 

reclptc.15 

This case tests 

THETA = -0.002569999999999999, 

G ROTATION = -0.00828 

RE CMD should be 6 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.3 

rec lp_nr_015.tc 

reclp_nr_015.ex 
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reclptc.16 

This case tests 

THETA = 0.002569999999999999, 

G ROTATION = -0.00828 

RE_CMD should be 1 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.4 

rec lp_nr_016.tc 

redp_nr_016.ex 

reclptc.17 

This case tests 
THETA = 0.00634 & 

G ROTATION = -0.00828 

RE CMD should be 7 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.6 

reclp_nr_017.tc 

redp_nr_017.ex 

reclptc.18 

This case test following: 

THETA = 0.00634 & 

G ROTATION = 0.00828 

RE CMD should be 7 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.6 

r edp_nr_018.tc 

redp_nr_018.ex 

reclptc.19 

This case test following: 

THETA = -0.00634 & 

G ROTATION = 0.00828 

RE CMD should be 6 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA. 1 

r edp_nr_019.tc 

redp_nr_019.ex 

r edp_tc.20 

This case test following: 

THETA = -0.00634 & 

G ROTATION = -0.00828 

RE CMD should be 6 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA. 1 

redp_nr_020.tc 

redp_nr_020.ex 

reclp_tc.2 1 

This case test following: 

THETA = 0.0042 & 

G ROTATION = 0.00826 

RE CMD should be 5 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.4 

r edp_nr_02 1 .tc 

redp_nr_02 1 .ex 

reclp tc.22 

This case test following: 

THETA = -0.0042 & 

G ROTATION = 0.00826 

RE CMD should be 1 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.3 

redp_nr_022.tc 

redp_nr_022 . ex 

reclp_tc.23 

This case test following: 

THETA = -0.0042 & 

G ROTATION = -0.00826 

RE CMD should be 4 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.3 

redp_nr_023.tc 

reclp_nr_023 .ex 

reclp_tc.24 

This case test following: 

THETA = 0.0042 & 

G ROTATION = -0.00826 

RE CMD should be 1 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.4 

r edp_nr_024.tc 

reclp_nr_024 . ex 
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r eelp_tc.25 

This case test following: 

THETA = 0.0065 & 

G ROTATION = -0.00826 

RE CMD should be 7 

Tests valid inputs and Equivalence Classes: 

G ROTATION. 1 

THETA.6 

reclp_nr_025.tc 

reclp_nr_025.ex 

r eelp_t c .26 

This case tests with: 
THETA = -0.0061, 
GROTATION = -0.00826 
RE CMD should be 6 

reclp_nr_026.tc 

reclp_nr_026.ex 

reclp_tc.27 

This case tests with: 
THETA = -0.0065, 
GROTATION = 0.00826 
RE CMD should be 6 

reclp_nr_027.tc 

reclp_nr_027.ex 

reclp tc.28 

This case tests with: 
THETA = 0.0061, 

G ROTATION = 0.00826 
RE CMD should be 7 

reclp_nr_028.tc 

re clp_ nr _028.ex 

reclp_tc.29 

This case tests with: 
THETA = 0.0061, 

G ROTATION = 0.009999 
RE CMD should be 7 

reclp_nr_029.tc 

reclp_nr_029.ex 

reclp_tc.30 

This case tests with: 
THETA = -0.0061, 
GROTATION = 0.009999 
RE CMD should be 6 

reclp_nr_030.tc 

reclp_nr_030.ex 

reelpteJl 

This case tests with: 

THETA = -0.0061, 
GROTATION = -0.009999 
RE CMD should be 6 

reclp_nr_03 1 .tc 

reclp_nr_03 1 .ex 

reclp tc.32 

This case tests with: 

THETA = 0.0065, 

G ROTATION = -0.009999 
RE CMD should be 7 

reclp_nr_032.tc 

reclp_nr_032.ex 

reclp tc.33 

This case tests with: 
THETA = 0.0063, 

G ROTATION = -0.00826 
RE CMD should be 7 

reclp_nr_033.tc 

reclp_nr_033.ex 

reclp_tc.34 

This case tests with: 
THETA = -0.0063, 
GROTATION = 0.00826 
RE CMD should be 6 

reclp_nr_034.tc 

reclp_nr_034.ex 

reclp_tc.35 

This case tests with: 
THETA = -0.0063, 

G ROTATION = 0.009999 
RE CMD should be 1 

r eclp_nr_035.tc 

reclp_nr_035.ex 

reclp_tc.36 

This case tests with: 

THETA = 0.0063, 

G ROTATION = -0.009999 
RE CMD should be 1 

reclp_nr_036.tc 

reclp_nr_036.ex 

reclp_tc.37 

This case tests with: 

THETA = -0.006400000000000001, 
GROTATION = 0.009999 
RE CMD should be 6 

reclp_nr_037.tc 

reclp_nr_037.ex 

reclp tc.38 

This case tests with: 

THETA = 0.006400000000000001, 
G ROTATION = -0.009999 
RE CMD should be 5 

reclp_nr_038.tc 

reclp_nr_038.ex 

reclp_tc.39 

This case tests with: 

THETA = 0.006400000000000001, 
G ROTATION = -0.0100001 
RE CMD should be 1 

reclp_nr_039.tc 

reclp_nr_039.ex 

rec lp_t c -40 

This case tests with: 

THETA = -0.006400000000000001, 
GROTATION = -0.0100001 
RE CMD should be 6 

reclp_nr_040.tc 

reclp_nr_040.ex 
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reelp t c -41 

This case tests with: 

THETA = -0.006400000000000001, 
G ROTATION = 0.0 100001 
RE CMD should be 1 

r eclp_nr_04 1 .tc 

reclp_nr_04 1 .ex 

reclp_tc.42 

This case tests with: 

THETA = 0.006400000000000001, 
G ROTATION = 0.0 100001 
RE CMD should be 7 

reclp_nr_042.tc 

reclp_nr_042 . ex 

r eelp_t c .43 

This case tests with: 

THETA = 0.006400000000000001, 
GROTATION = -0.015709 
RE CMD should be 6 

reclp_nr_043.tc 

reclp_nr_043.ex 

reelp te.44 

This case tests with: 

THETA = 0.006400000000000001, 
G ROTATION = 0.015709 
RE CMD should be 7 

r eclp_nr_044.tc 

reclp_nr_044 . ex 

r e c lp_te.45 

This case tests the +P2 boundary with Theta > 0. These numbers are 
valid but not necessarily realistic for GCS. 

THETA = 0.038, 

G ROTATION = 0.02 == P2 
RE CMD should be 5 

r eclp_nr_045.tc 

reclp_nr_045.ex 

r e c lp_te.46 

This case tests the -P2 boundary with Theta < 0. These numbers are 
valid but not necessarily realistic for GCS. 

THETA = -0.038, 

G ROTATION = -0.02 == -P2 
RE CMD should be 5 

reclp_nr_046.tc 

reclp_nr_046 . ex 

reclp_tc.47 

Boundary test with 
THETA = 0.039, 

G ROTATION = 0.01 =P1 
RE CMD should be 3 

r eclp_nr_047.tc 

reclp_nr_047.ex 

r eelp_t c .48 

Boundary test with 
THETA = -0.039, 

G ROTATION = -0.01 = -PI 
RE CMD should be 2 

reclp_nr_048.tc 

reclp_nr_048 .ex 

reelp te.49 

Boundary test with 
THETA = 0.019, 

G ROTATION = 0.01 == PI 
RE CMD should be 1 

r eclp_nr_049.tc 

reclp_nr_049.ex 

reclp_tc.50 

Boundary test with 
THETA = -0.019, 

G ROTATION = -0.01 ==-Pl 
RE CMD should be 1 

reclp_nr_050.tc 

reclp_nr_050.ex 

reclp_tc.51 

Boundary test for -THETA2 with 
THETA = -0.04 == -THETA2, 

G ROTATION = 0.01 ==P1 
RE CMD should be 1 

reclp_nr_05 1 .tc 

reclp_nr_05 1 .ex 

reclp_tc.52 

Boundary test with 
THETA = -0.042, 

G ROTATION = 0.02 == P2 
RE CMD should be 1 

reclp_nr_052.tc 

reclp_nr_052.ex 

reclp_tc.53 

Boundary test with 
THETA = -0.04299999999999999, 
G ROTATION = 0.03 == P3 
RE CMD should be 1 

reclp_nr_053.tc 

reclp_nr_053.ex 

r eelp_t c .54 

Boundary test with 
THETA = -0.044, 

G ROTATION = 0.04 == P4 
RE CMD should be 1 

r eclp_nr_054.tc 

reclp_nr_054.ex 

reclp_tc.55 

Boundary test with 
THETA = 0.04 == THETA2, 
G ROTATION = -0.01== PI 
RE CMD should be 1 

reclp_nr_055.tc 

reclp_nr_055.ex 

r e c lp_te.56 

Boundary test with 
THETA = 0.042, 

G ROTATION = -0.02 == -P2 
RE CMD should be 1 

r eclp_nr_056.tc 

reclp_nr_056.ex 
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reclp_tc.57 Boundary test with 

THETA = 0.04299999999999999, 
GROTATION = -0.03 == -P3 

RE CMP should be 1 

reclp_tc.58 Boundary test with 

THETA = 0.044, 

GROTATION = -0.04 == -P4 

RE CMP should be 1 

reclp_tc.59 Boundary test with 

THETA = -0.004, 

GROTATION = 0.04 == P4 

RE CMP should be 1 

reclp_tc.60 This case tests with: 

THETA = 0.0157079632679441, 
G_ROTATION= 1.01 

RE CMP should be 7 

reclp_tc.61 This case tests with: 

THETA = 0.0157079632679441, 
GROTATION = -1.01 

RE CMP should be 7 

reclp_tc.62 This case tests with: 

THETA = 3 . 1 4767 1 865 1 402, 
GROTATION = 0.5 

RE CMP should be 7 

reclp_tc.63 This case tests with: 

THETA = -3.1476718651402, 
GROTATION = 0.5 

RE CMP should be 7 

reclp_tc.64 This case tests with: 

THETA = -0.05, 

GROTATION = 0.5 

RE CMP should be 7 

reclp_tc.65 Test origin: 

THETA = 0., 

GROTATION = 0 

RE CMP should be 1 

reclp_tc.66 Test THETA at -Pi: 

THETA = -3.1476718651402, 
GROTATION = 0 
RE CMP should be 6 
reclp_tc.67 Test THETA at Pi: 

THETA = 3 . 1 4767 1 865 1 402, 
GROTATION = 0 

RE CMP should be 7 

reclp_tc.68 This case tests with: 

THETA = 0.05, 

GROTATION = -0.5 
RE CMP should be 6 



rec lp_nr_057.tc 

reclp_nr_057.ex 


reclp_nr_058.tc 

reclp_ nr _058.ex 


reclp_nr_059.tc 

reclp_nr_059.ex 


rec lp_ r °_060.tc 

reclp_ro_060.ex 


rec lp_ r °_06 \ t c 

reclp_ro_06 1 .ex 


rec lp_ r °_062.tc 

reclp_ro_062.ex 


rec lp_ r °_063.tc 

reclp_ro_063.ex 


reclp_nr_064.tc 

reclp_nr_064.ex 


r eelp_nr_065.tc 

reclp_nr_065.ex 


reclp_nr_066.tc 

reclp_nr_066.ex 


rec lp_nr_067.tc 

reclp_nr_067.ex 


reclp_nr_068.tc 


reclp_nr_068.ex 





A.3.10 CRCP Functional Unit Test Cases 


Table A. 14 gives a listing of all requirements-based test cases for the CRCP functional unit. 
Since only two variables are involved in the testing, their values are also given for each test case. 
All test cases manipulate the variables: 


AETEMP 

CHUTERELEASED 


Table A. 14: Test cases for CRCP functional unit. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

crcptc. 1 

Test initial frame with: 

AE TEMP = 0, CHUTERELEASE = 0 

crcp nr 00 l.tc 

crcp nr 00 l.ex 

crcp_tc.2 

AE TEMP = 0, CHUTE RELEASE = 1 
This is a valid, but unlikely case. 

crcp nr 002 .tc 

crcp nr 002. ex 

crcp_tc.3 

Frame 25 1 : 

AE TEMP = 1, CHUTE RELEASE = 0 

crcp_nr_003.tc 

crcp_nr_003.ex 

crcp_tc.4 

Frame 25 1 : 

AE TEMP = 1, CHUTE RELEASE = 1 
This is a valid, but unlikely case. 

crcp nr 004.tc 

crcp nr 004. ex 

crcp_tc.5 

Frame 252: 

AE TEMP = 2, CHUTE RELEASE = 0 

crcp_nr_005.tc 

crcp_nr_005.ex 

crcp_tc.6 

Frame 252: 

AE TEMP = 2, CHUTE RELEASE = 1 

crcp_nr_006.tc 

crcp_nr_006.ex 

crcp_tc.7 

Frame 252: 

AE TEMP = 0, CHUTE RELEASE = -1 
This is a valid, but unlikely case. 

crcp_ro_007.tc 

crcp_ro_007.ex 

crcp_tc.8 

Frame 252: 

AE TEMP = 0, CHUTE RELEASE = 2 
This is a valid, but unlikely case. 

crcp_ro_008.tc 

crcp_ro_008.ex 

crcp_tc.9 

AE TEMP = 3, CHUTE RELEASE = 0 
This is a valid, but unlikely case. 

crcp_ro_009.tc 

crcp_ro_009.ex 

crcptc. 1 0 

AE TEMP = -1, CHUTE RELEASE = 0 
This is a valid, but unlikely case. 

crcproOlO.tc 

crcproOlO.ex 
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A.3.11 CP Functional Unit Test Cases 


CP requirements-based functional unit test cases are given in Table A. 15. All test cases 
manipulate the variables: 


FRAMECOUNTER 
SUBFRAME COUNTER 


Even though the GCS Specification lists many more variables as inputs for CP, the specific 
value of the variables do not effect the operation of CP. The CP functional unit only copies these 
values to the PACKET array. The variables are not used for decision in CP. Therefore, it is 
unnecessary to test specific values of those variables. The only two variables that influence CP 
operation are the ones listed above. 


Table A. 15: Test cases for CP functional unit. 


Test Case Data 
File 

Description 

Test-Input File 

Expected-Results 

File 

cp nr OOl.m 

Test Packet and CRC generation for subframe 1 
variables 

cp_nr_001.tc 

cpnrOO 1 .ex 

cp nr 002. m 

Test Packet and CRC generation for subframe 2 
variables 

cp_nr_002.tc 

cp_nr_002.ex 

cp_nr_003.m 

Test Packet and CRC generation for subframe 3 
variables 

cp_nr_003.tc 

cp_nr_003.ex 

cp nr 004. m 

Test Packet and CRC generation for subframe 1 
variables when frame number is greater than 1 

cp_nr_004.tc 

cp nr 004. ex 

cp_nr_005.m 

Test Packet and CRC generation for subframe 1 
variables when sequence number is greater than 255 

cp_nr_005.tc 

cp_nr_005.ex 
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A.3.12 SP Subframe Test Cases 


All four of the requirements of SP subframe as listed in the traceability matrix, Table A. 10-1, 
are tested by test case SP00 1 . It tests to see if the TSP calculations are performed before other 
functional units, verifies that all other functional units execute including CP. The data file 
sp OOl.m is used to generate the test-input file spOOl.tc and the expected results file sp OOl.ex. 

A.3.13 GP Subframe Test Cases 

Table A. 16 gives the test cases for the GP subframe. Since the GP subframe has only the GP 
functional unit, tests of this subframe will be similar to test of the GP functional unit. The 
difference is that subframe test also include calling CP to create the communications packet for 
the GP subframe. 


Table A. 16: Test cases for GP Subframe. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

gpsftc.l 

Initial frame, tests all valid inputs 

gpsf_001.tc 

gpsf_00 1 .ex 

gpsf_tc.2 

Transition frame 246. 

gpsf_002.tc 

gpsf_002.ex 

gpsf_tc.3 

FRAME = 251; CHUTERELEASED set to 1 this 
frame. All valid inputs tested. 

gpsf_003.tc 

gpsf_003.es 

gpsf_tc.4 

FRAME = 252; CHUTE RELEASED = 1 & 
GP PHASE goes to 3 

gpsf_004.tc 

gpsf_004.ex 

gpsf_tc.5 

FRAME = 950 CONTOUR_CROSSED will be set to 1 
by the end of the frame. All valid data tested. 

gpsf_005.tc 

gpsf_005.ex 

gpsf_tc.6 

FRAME = 951 with CONTOUR_CROSSED = 1 

gpsf_006.tc 

gpsf_006.ex 

gpsf_tc.7 

FRAME = 2073 where CL = 2. All valid data tested. 

gpsf_007.tc 

gpsf_007.ex 

gpsf_tc.8 

FRAME = 2078 with CL = 2, and GP_PHASE changes 
to 4. All valid data tested. 

gpsf_008.tc 

gpsf_008.ex 
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A.3.14 CLP Subframe Test Cases 


CLP subframe test cases are given in Table A. 17. Since the AECLP functional unit must be 
executed first in this subframe, CLP subframe test cases data is depends heavily on the AECLP 
inputs. As can be seen from the traceability matrix (Table A. 10-1), each CLP test case will test 
all four of the CLP subframe requirements. 


Table A. 17: Test cases for CLP Subframe. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

clptc. 1 

Test initial frame using data from aeclp tc. 1 

clpOOl.tc 

clpOOl.ex 

clp_tc.2 

Test frame 2 using data from aeclp tc.2 

clp_002.tc 

clp_002.ex 

clp_tc.3 

Test frame 251 using data from aeclp tc.3 

clp_003.tc 

clp_003.es 

clp_tc.4 

Test frame 252 using data from aeclp tc.4 

clp_004.tc 

clp_004.ex 

clp_tc.5 

Test frame 950 using data from aeclp tc.5 

clp_005.tc 

clp_005.ex 

clp_tc.6 

Test frame 951 using data from aeclp tc.6 

clp_006.tc 

clp_006.ex 

clp_tc.7 

Test frame 2077 using data from aeclp tc.7 

clp_007.tc 

clp_007.ex 

clp_tc.8 

Test frame 2078 using data from aeclp tc.8 

clp_008.tc 

clp_008.ex 

clp_tc.9 

Test frame 2083 using data from aeclp tc.9 

clp_009.tc 

clp_009.es 

clptc.10 

Test frame 250 using data from aeclp tc. 10 

clpOlO.tc 

clpOlO.ex 

clptc. 1 1 

Test frame 949 using data from aeclp tc. 1 1 

clpOl l.tc 

clp Ol Lex 

clp_tc,12 

Test frame 955 using data from aeclp tc. 12 

clp_012.tc 

clp_012.ex 

clptc.13 

Test using aeclp tc. 54 data where AE SWITCH 
is still off at end of frame, giving AE CMD = 0 
FRAMEENGINESIGNITED > 1 

clp_013.tc 

clp_013.ex 

clp_tc,14 

Test using aeclp tc.55 data where 
INTERN ALCMD >1.0 

clp_014.tc 

clp_014.ex 
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A.3.15 Frame Test Cases 


Frame test cases are given in Table A. 18. They exercise all functional units for frames with 
significant transitions during the terminal descent. These transition include changes in 
GPPHASE or other trajectory status variables and are given in the Table A. 10-1. 


Table A. 18: Frame test cases. 


Test Case 
Data File 

Description 

Test-Input File 

Expected- 
Results File 

frame tc. 1 

Test initial frame with frame counter set to 1. All 
valid data used. 

frame 00 l.tc 

frame 00 l.ex 

frame tc.2 

Test frame 246 where GP PHASE = 2. This is the 
frame that occurs just before AE TEMP transitions 
from 1 to 2 and CHUTE RELEASED transitions 
from 0 to 1 . 

frame 002. tc 

frame 002. ex 

frame tc.3 

Test frame 251 where GP PHASE = 2. This is the 
frame that occurs just before AE TEMP transitions 
from 1 to 2 and CHUTE RELEASED transitions 
from 0 to 1 . 

frame 003. tc 

frame 003.es 

frame tc.4 

Test frame 252 where GP PHASE transitions from 
2 to 3. 

frame 004.tc 

frame 004. ex 

frame tc.5 

Test frame where CONTOURCROSSED 
transitions from 0 to 1 . 

frame 005. tc 

frame 005. ex 

frame tc.6 

Test the frame just after CONTOUR CROSSED 
transitions to 1. This case added for completeness. 

frame 006.tc 

frame 006. ex 

frame tc.7 

Test the frame when CL = 2. 

frame 007.tc 

frame 007. ex 

frame tc.8 

Test frame when GP PHASE transitions from 3 to 
4. 

frame 008.tc 

frame 008. ex 

frame tc.9 

Test frame when GP PHASE starts as 5; no 
execution should occur. 

frame 009.tc 

frame 009. ex 
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A.3.16 Trajectory Test Cases 

The ultimate goal of each GCS implementation is to land the spacecraft safely given some 
initial set of parameters. These parameters reflect environmental conditions, the spacecraft, and 
the flight conditions at the beginning of the terminal descent. In full trajectory testing, each 
implementation’s code is linked and run in the simulator's environment. Unlike previous tests 
which exercise the implementation as a stand-alone process, trajectory testing requires the 
implementation to run as a subprocess of the simulator program. This is part of the high level 
requirements. Additionally, the GCS Specification requires the implementation to be able to 
execute multiple consecutive frames until the termination condition is reached. Since a landing is 
not specifically stated as a high level requirement of the GCS software, trajectory testing will 
encompass both successful landing cases and expected crash cases and will cover the part of the 
simulator's input space that directly effects the implementation. Keep in mind that the objective 
of trajectory testing is to verify each implementation's ability to run consecutive and multiple 
frames. Whether the final result is a landing or a crash is inconsequential. 

It is assumed for testing purposes that the GCS Simulator provides a stable model of the flight 
and atmospheric dynamics when given a set of initial conditions. This is significant because test 
case inputs for trajectory testing are parameters for the simulator, not the implementation. There 
are nominally four sets of input parameters for the simulator. They are physical parameters of the 
Viking Lander, aerodynamic response of the Lander, the atmospheric conditions during descent, 
and the terminal descent conditions of the vehicle. Of these four sets, the atmospheric and initial 
entry conditions have been identified to most directly effect the implementations and hence will 
be considered as the input space for the implementation running under the simulator. The 
physical parameters for the Lander will not be considered because modifying these parameters 
could constitute testing various configurations of the vehicle and are beyond the scope of testing 
GCS implementations. The aerodynamic responses of the vehicle are also not considered to be 
part of the input space because they are used by the simulator. Section 2. 1.2.2 of the GCS SIM 
User's Guide (ref. A.5) even gives staunch warning about modifications to this data set. 

The specific parameters to be considered for trajectory tests are given below for the two 
categories. 

Atmospheric Conditions parameters: 

Initial Wind Velocity 
windgradiant 
Initial Temperature 
temperaturegradiant 
Terminal Descent parameters: 

Initial Altitude 
Rotation Rates(x,y,z) 

Velocity(x,y,z) 

Rotational Angle around (-y,-z, x) 

All parameters are in the USAGE_DISTRIBUTION.DAT input file for the GCS simulator 
except for windgradiant, and temperaturegradiant which are found in the 
INITIAL_CONSTANTS.DAT file. Hence, trajectory test cases inputs will consist of versions of 
these two files with carefully selected values for the above variables. Special instructions for 
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modifying values in the USAGE_DISTRIBUTIONS.DAT and INITIAL_CONSTANTS.DAT 
files are given in Section 2. 1.2.1 of the GCSSIM User's Guide. 

The GCS simulator is capable of selecting its own initial conditions based on the values in the 
USAGE_DISTRIBUTION.DAT file if those values are given in the form of a distribution. It 
does so based on a seed for a random number generator which it also selects if one is not 
specified. For trajectory tests, a seed will be specified although it is understood that the seed will 
not effect the specific values being tested because the values in the 
USAGE_DISTRIBUTION.DAT file will be specified in a manner that forces those specific 
values to be the specified ones. The seed is used to select values for other variables not being 
tested. To be consistent, the same seed will be used for all trajectory test cases. This seed will be 
1 14291523 and it is set in the RErN_TRAJ.COM file. 

Specific values used for atmospheric test cases are given in Table A. 19 along with the test case 
names. The limiting and optimal values for the parameters are derived from the GCS subsystem 
description in the Viking 75 (ref. A.6) and from the GCS Specification. The optimal wind 
velocity is given as 51m/s while the maximum is given as 90m/s; the minimum is obviously Om/s. 
The simulator allows wind gradient to vary from -1.10 x 10"2 to 1.10 x 10"2. The units are 
derived based on analysis of the GCS simulator. The limiting values of -200 to 25 degrees are 
based on the GCS Specification for the range of the ATMOSPHERIC TEMP variable. A linear 
temperature gradient is calculated based on a 1.5 km drop mentioned in the GCS Specification. 
Note in the table below that nominal(N) values are used for all elements other than the variable of 
specific interest for a test case. The nominal value is the value picked by the simulator software 
given the above seed value. This is a consistent value for all test cases because all test cases will 
be run using the same seed. A sample of the nominal value range is in the GCSSIM User's 
Guide. 


Table A. 19: Atmospheric Test Cases 


Initial Wind 
Velocity 

WindGradient 

(/sec) 

Initial 

Temp 

Temp gradient 
(degree/km) 

Test Case 
Number 

90 

N 

N 

N 

001 j 

0 

N 

N 

N 

002 

51 

N 

N 

N 

003 

N 

-1. lOxlO- 2 

N 

N 

004 

N 

0 

N 

N 

005 

N 

1. lOxlO' 2 

N 

N 

006 

N 

N 

-200 

N 

007 | 

N 

N 

0 

N 

008 ! 

N 

N 

25 

N 

009 

N 

N 

N 

150 

010 

N 

N 

N 

0 

Oil 

N 

N 

N 

-150 

012 


Specific values for terminal descent condition test cases are given in Table A.4. Limiting 
values for initial altitude are 2000 meters (maximum value for altitude variables given in the 
Specification) and 1400 meters (optimal altitude given in (ref. A.6)). A value of 0 is a legal value 
for altitude but would not be applicable for an initial altitude. Rotation rates of -1.0 rad/sec to 1.0 
rad/sec are permitted by the simulator software. No information is available on the velocity 
range. Hence the range given by the usage distribution in the GCS SIM User's Guide (p. 12) was 
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used. It allows the X and Y velocity to vary between ±20 m/s and the Z velocity to vary between 
0 and 200 m/s. The Rotational Angles are used by the simulator to calculate the initial attitude 
cosines. No limits for the rotation angles were found while reviewing the simulator code for 
calculating the attitude cosines. However, tests of the simulator software show that the -Y and -Z 
rotation angles can vary between ±0.83 rads and the X rotation angle can vary from 0 to 2n. 


Table A.20: Terminal Descent test cases 


Initial 

Rotation Rates 

Velocity 

Vehicle Orientation 

Test Case 

Altitude 

X 

y 

z 

X 

y 

z 

X 

y 

z 

Number 

(m) 

(rad/s) 

(rad/s) 

(rad/s) 

(m/s) 

(m/s) 

(m/s) 

(rad) 

(rad) 

(rad) 


2000 

N 

N 

N 

N 

N 

N 

N 

N 

N 

013 

1400 

N 

N 

N 

N 

N 

N 

N 

N 

N 

014 

700 

N 

N 

N 

N 

N 

N 

N 

N 

N 

015 

N 

N 

N 

N 

-20 

N 

N 

N 

N 

N 

016 

N 

N 

N 

N 

20 

N 

N 

N 

N 

N 

017 

N 

N 

N 

N 

N 

-20 

N 

N 

N 

N 

018 

N 

N 

N 

N 

N 

20 

N 

N 

N 

N 

019 

N 

N 

N 

N 

N 

N 

0 

N 

N 

N 

020 

N 

N 

N 

N 

N 

N 

200 

N 

N 

N 

021 

N 

N 

N 

N 

0 

0 

N 

N 

N 

N 

022 

N 

N 

N 

N 

N 

N 

N 

0 

N 

N 

023 

N 

N 

N 

N 

N 

N 

N 

6.28 

N 

N 

024 

N 

N 

N 

N 

N 

N 

N 

N 

-0.83 

N 

025 

N 

N 

N 

N 

N 

N 

N 

N 

0.83 

N 

026 

N 

N 

N 

N 

N 

N 

N 

N 

N 

-0.83 

027 

N 

N 

N 

N 

N 

N 

N 

N 

N 

0.83 

028 

N 

1 

N 

N 

N 

N 

N 

N 

N 

N 

029 

N 

-1 

N 

N 

N 

N 

N 

N 

N 

N 

030 

N 

N 

1 

N 

N 

N 

N 

N 

N 

N 

031 

N 

N 

-1 

N 

N 

N 

N 

N 

N 

N 

032 

N 

N 

N 

1 

N 

N 

N 

N 

N 

N 

033 

N 

N 

N 

-1 

N 

N 

N 

N 

N 

N 

034 
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The nominal values selected by using the standard seed for the above test cases are as follows: 


Initial altitude: 


1498.24 meters 


Rotation Rates: (rad/sec) 

about x 

-6.14 x lO' 2 

about y 

-8.80 x 10- 2 

about z 

-9.92 x IQ' 2 

Velocity (meters/sec) 

X 

-1.58 

y 

20 

z 

57.03 

Initial wind velocity 

24.71 m/sec 

Initial temperature 

-140.56° C 

Orientation Angles (radian) 

about x 

0.20 

about -y 

-0.17 

about -z 

-1.17 


Tables A. 19 and A.20 give specific input values for all trajectory test cases. To be consistent 
with other sections above, Table A.21 is included to summarize all trajectory test cases for use 
with test case generation and execution procedures. 
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Table A.21: Trajectory test case summary. 


Test Case Data 
File 

Description 

Test-Input File 

Expected-Results 

File 

traj atm ic OOl.tc 
traj atm ud OOl.tc 

Test high wind velocity 

traj atm ic OOl.tc 
traj atm ud OOl.tc 

traj atm 001. seed 

traj atm ic 002. tc 
traj atm ud 002. tc 

Test no wind 

traj atm ic 002. tc 
traj_atm_ud_002 . tc 

traj atm 002. seed 

traj atm ic 003. tc 
traj atm ud 003. tc 

Test optimal velocity 

traj atm ic 003. tc 
traj_atm_ud_003.tc 

traj atm 003. seed 

traj atm ic 004.tc 
traj atm ud 004. tc 

Test low wind gradient 

traj atm ic 004. tc 
traj atm ud 004. tc 

traj atm 004. seed 

traj atm ic 005. tc 
traj atm ud 005. tc 

Test 0 wind gradient 

traj atm ic 005. tc 
traj atm ud 005. tc 

traj atm 005. seed 

traj atm ic 006.tc 
traj atm ud 006. tc 

Test high wind gradient 

traj atm ic 006. tc 
traj atm ud 006. tc 

traj atm 006. seed 

traj atm ic 007. tc 
traj atm ud 007.tc 

Test low initial temp. 

traj atm ic 007. tc 
traj_atm_ud_00 7 . tc 

traj atm 007. seed 

traj atm ic 008.tc 
traj atm ud 008. tc 

Test 0 initial temp. 

traj atm ic 008. tc 
traj atm ud 008.tc 

traj atm 008. seed 

traj atm ic 009.tc 
traj atm ud 009. tc 

Test high initial temp. 

traj atm ic 009. tc 
traj atm ud 009. tc 

traj atm 009. seed 

traj atm ic OlO.tc 
traj atm ud OlO.tc 

Test high temp, gradient 

traj atm ic OlO.tc 
traj atm ud OlO.tc 

traj atm 010. seed 

traj atm ic Oil .tc 
traj atm ud Oll.tc 

Test 0 temp, gradient 

traj atm ic Oll.tc 
traj atm ud Oll.tc 

traj atm Oil. seed 

traj atm ic 012.tc 
traj atm ud 012.tc 

Test low temp gradient 

traj atm ic 012. tc 
traj atm ud 012.tc 

traj atm 012. seed 

traj td ic 013.tc 
trajtdudO 1 3 .tc 

Test highest initial altitude 

trajtdicO 1 3 .tc 
traj_td_ud_OI3.tc 

traj _td_0 13. seed 

traj td ic 014.tc 
trajtdudO 1 4 .tc 

Test optimal altitude 

traj_td_ic_014.tc 

traj_td_ud_014.tc 

traj_td_014.seed 

traj td ic 015.tc 
trajtdudO 1 5 .tc 

Test lowest altitude 

traj_td_ic_015.tc 

traj_td_ud_015.tc 

traj _td_0 15. seed 

traj td ic 016.tc 
trajtdudO 1 6 . tc 

Test X velocity min. value 

traj td ic 016.tc 
trajtdudO 1 6.tc 

traj_td_016.seed 

traj td ic 017.tc 
trajtdudO 1 7 . tc 

Test X velocity max. 
value. 

traj_td_ic_017.tc 

traj_td_ud_017.tc 

traj_td_017.seed 

traj td ic 018.tc 
trajtdudO 1 8 .tc 

Test Y velocity min. value 

traj_td_ic_018.tc 

traj_td_ud_OI8.tc 

traj_td_018.seed 

traj td ic 019.tc 
trajtdudO 1 9 . tc 

Test Y velocity max. 
value. 

traj_td_ic_019.tc 

traj_td_ud_019.tc 

traj_td_019.seed 

traj td ic 020.tc 
traj_td_ud_020.tc 

Test Z velocity min. value 

traj_td_ic_020.tc 

traj_td_ud_020.tc 

traj_td_020.seed 

traj td ic 021.tc 
traj_td_ud_02 1 .tc 

Test Z velocity max. 
value. 

traj_td_ic_021.tc 

traj_td_ud_021.tc 

traj _td_021. seed 
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traj td ic 022.tc 
traj_td_ud_022.tc 

Test no X & Y velocity 

traj td ic 022. tc 
traj _td_ud_022 . tc 

traj _td_022. seed 

traj td ic 023. tc 
traj_td_ud_023 .tc 

Test min. X entry angle 

traj_td_ic_023.tc 

traj_td_ud_023.tc 

traj _td_023. seed 

traj td ic 024. tc 
traj_td_ud_024.tc 

Test max. X entry angle 

traj_td_ic_024.tc 

traj_td_ud_024.tc 

traj_td_024.seed 

traj td ic 025. tc 
traj_td_ud_025 .tc 

Test min. Y entry angle 

traj td ic 025. tc 
traj_td_ud_025.tc 

traj _td_025. seed 

traj td ic 026.tc 
traj_td_ud_026.tc 

Test max. Y entry angle 

traj td ic 026. tc 
traj_td_ud_026.tc 

traj_td_026.seed 

traj td ic 027.tc 
traj_td_ud_027.tc 

Test min. Z entry angle 

traj_td_ic_027.tc 

traj_td_ud_027.tc 

traj_td_027.seed 

traj td ic 028.tc 
traj_td_ud_02 8 .tc 

Test max. Z entry angle 

traj_td_ic_028.tc 

traj_td_ud_028.tc 

traj_td_028.seed 

traj td ic 029.tc 
traj_td_ud_029.tc 

Test positive X rotation 
rate 

traj_td_ic_029.tc 

traj_td_ud_029.tc 

traj_td_029.seed 

traj_td_ic_030.tc 

traj_td_ud_030.tc 

Test negative X rotation 
rate 

traj_td_ic_030.tc 

traj_td_ud_030.tc 

traj_td_030.seed 

traj td ic 031.tc 
traj _td_ud_0 3 1 .tc 

Test positive Y rotation 
rate 

traj_td_ic_03 1 .tc 
traj_td_ud_03 1 .tc 

traj _td_031. seed 

traj td ic 032.tc 
traj_td_ud_032.tc 

Test negative Y rotation 
rate 

traj_td_ic_032.tc 

traj_td_ud_032.tc 

traj_td_032.seed 

traj _td_ i c_0 3 3 . tc 
traj _td_ud_0 3 3 .tc 

Test positive Z rotation 
rate 

traj_td_ic_033.tc 

traj_td_ud_033.tc 

traj_td_033.seed 

traj td ic 034.tc 
traj_td_ud_034.tc 

Test negative Z rotation 
rate 

traj_td_ic_034.tc 

traj_td_ud_034.tc 

traj_td_034.seed 
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A.3.17 Pass/Fail Criteria 


This section focuses on the strategy used to determine pass or failure of a test case. Two 
techniques are used to determine whether a test case passes or fails. The first is applicable to 
functional unit, subframe, frame, and structural test cases. Trajectory cases use a different 
technique because those cases are run with the GCS simulator. 

The GCS Specification requires all data flow, into and out of the software, to go through the 
four data stores. Hence, results of any functional unit can be checked by examining the data in 
the stores after the functional unit has executed. To determine whether a test case passes or fails, 
test drivers compare the values of the data store with values from the expected-results file. If all 
variables match their expected results, the test case passes. To further simplify the matching 
process, the expected-results file uses the same NAMELIST format as the data stores. 

The criteria for what constitutes a correct match varies for different variables. For variables 
defined as INTEGERS and LOGICALS an exact match between the expected and actual results is 
required. For real variables, the value generated during the test run must match to within a 
tolerance of the expected value. The tolerances are determined based on empirical experience 
with the GCS simulator and vary for different variables. The tolerance calculation is different for 
the two sets of variables as given in Table A.22 and A.23. For variables listed in Table A.22, the 
tolerance is either the absolute error (e) or the relative error (8) depending on whether the values 
is less than the threshold ((3), which is also empirically determined. For variables listed in Table 
A.23, the tolerance is the absolute error (e). 


Table A.22: Accuracy tolerances for variables in set 1. 


Data Element Name 

P 

£ 

8 

A_ACCELERATION(1,0) 

1.0 

.001 

5.0D-9 

ARALTITUDE 

1.0 

.001 

5.0D-10 

ATMOSPHERICTEMP 

1.0 

.001 

5.0D-10 

GPALTITUDE 

5.0 

.01 

5.0D-5 

GPVELOCITY 

1.0 

.001 

5.0D-6 

TDLRVELOCITY 

1.0 

.001 

5.0D-10 

TELIMIT 

1.0 

.001 

5.0D-2 
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Table A.23: Accuracy tolerances for variables in set 2. 


Data Element Name 

e 

A_ACCELERATION(2,0) 

.001 

AACCELERATION (3,0) 

.001 

GROTATION 

.001 

GPATTITUDE 

.001 

GPROTATION 

.001 

INTERNALCMD 

.001 

PEINTEGRAL 

.001 

TEINTEGRAL 

.001 

THETA 

.01 

VELOCITYERROR 

.001 

YE INTEGRAL 

.001 


It should be noted that the GCS simulator performs accuracy checks on only the current values 
of the variables. For testing purposes, all history values of all variables must be checked to ensure 
that data store integrity is maintained. To reduce the complexity of the comparison, test drivers 
are set up to generate an output file if a mismatch is found for any variable. An absolute error 
more than 1.0 x 10'^ is considered a mismatch fortesting purposes 

When a trajectory is run, one of the output files gives the starting seed, ending seed, whether 
the space craft landed, the number of frames executed, and the final value of GPPHASE. This 
information is sufficient to determine whether the trajectory is run to completion and whether a 
landing or a crash has occurred. More importantly, the number of frames and the final value of 
GP PHASE can be used to determine whether the high level requirements have been met, since 
the highest level requirement is for each implementation to run consecutive and multiple frames 
until the GP PHASE is 5. If the ".SEED" output file for any trajectory test cases shows that 
multiple frames were executed and that the final value of GP PHASE is 5, then the 
implementation can be considered to have met the high-level requirements. In addition to visual 
survey of the “.SEED” files, the trajectory test case execution procedure includes an additional 
step to compare the output seed files with those from the VENUS prototype. This is an additional 
check to match the implementation to the VENUS prototype. 

A.4 Test Case Execution Procedures 

Once test cases and drivers have been developed and submitted to configuration management, 
the verification analysts are ready to initiate testing of the GCS implementations. Given that the 
GCS development activities follow the water-fall model, all the code is available when testing 
commences. This is consistent with the requirements in DO-178B. Further, DO-178B requires 
GCS testing to be conducted in the following order: 

1) requirements-based functional unit testing. 

2) requirements-based subframe testing 

3) requirements-based frame testing 

4) requirements-based trajectory testing 
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5) structural analysis and testing of functional units 

The general procedure for any of the above categories of testing is to first request the 
configuration items necessary for the test, place them in the appropriate directories, build the test 
case with the test subjects, run the command file that executes the test suite, check for any 
analysis files, determine if the items in the analysis file warrant problem reporting. If code 
modifications are made, then all test cases for the changed code are re-executed. The sections 
below will describe the directory structure that must be created to execute the test cases. The 
specific configuration items and execution procedures necessary for the test case are also be 
described. 

A.4.1 Environment and Directory Structure for Test Case Execution 

GCS implementations are written in VAX FORTRAN and are intended for execution on DEC 
machines. To perform functional unit testing of GCS implementations, it is necessary to have a 
directory structure that matches the DCL commands in the test support files. Otherwise, those 
path names need to be edited to reflect the directory structure of the specific user. The figure 
below illustrates the directory structure that a Verification Analyst must have for testing to avoid 
excessive editing to support files. 



Note that the top level directory, "USER", is the user's home directory. The TEST_DRIVER 
directory is used for storing the test drivers and support files. The TEST CASES directory has a 
series of subdirectories. There should be a subdirectory for each functional unit although not all 
are shown. There should also be a subdirectory for each subframe and one for frame test cases as 
shown. The IMPLEMENTATION directory is for storing the code to be tested. The name 
should be changed to the name of the appropriate implementation. The test case execution 
procedures will reference these directories for storing items Fetched from CMS. Again, it is 
important that the naming of the directories be adhered to as the DCL command files will 
reference those specific names. 

For trajectory testing, a separate [TRAJ] directory is needed for trajectory tests with two sub 
directories. The [TRAJ] directory will hold the simulator, the implementation to be tested, and 
the data and support files required for trajectory testing. The [ATM] subdirectory will hold the 
tests that vary the atmospheric conditions; the [TD] sub directory will hold the test cases that vary 
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the initial terminal descent conditions. Each sub directory will also contain an [OUT] directory 
for simulator output. The [TRAJ] directory will contain the ".COM" files and executables for the 
implementation and the simulator. 


A.4.2 Functional Unit Test Case Execution Procedure 

The following describes specific steps that must be followed for executing functional unit test 
cases. Because this procedure is written for both the Pluto and Mercury implementations, some 
file renaming will be necessary to account for the way files are stored in CMS. Additionally, 
directory references must be changed to account for the tester's top level directory name. 

1) Fetch all the code belonging to an implementation and place the code files in the 
[: implementation ] directory: 

Because specific file names will vary between implementations, all source files related to 
an implementation should be fetched. Extra files are of no consequence since the link 
command files will not use them. The link command filesfobtained in the next step) will 
li nk only the necessary files for a functional unit test concerned and disregard the extra 
files. 

2) Fetch the following data, support and utility files from the CMS library. Place them in their 
respective directories. Refer to Table A. 1 for specific names. 


Data files 

[TEST CASES. functional- 
unit] 

i Support Files 

; (directory below) 

l 

* Utility Files 

| [TESTDRIVERS] 

1 

l 

functional-unit _ NRxx.TC, .EX 
functional-unit _R0 _xx. TC, .EX 

- i_LNKfunctional-unit.COM 

; -> 

[IMPLEMENTATION.LNK] 
. / TEST Junctional-unit. FOR 
; -> [TEST DRIVERS] 

- COMPARE EXTERNAL. FOR 
; COMPARE GUIDANCE.FOR 

COMPARE RUNPRAM.FOR 
I READ TC.FOR 
READ EX. FOR 
! STRUCT.FOR INC 
; COMMONS.FOR INC 

- i TC DRIVER.COM 


Note that the represents the initial of the implementation. That is "M_" for Mercury 
and "P " for Pluto; the xxx represents the three digits identifying the test case; and 
functional-unit is replaced by the name of the functional unit (e.g. ASP, GP). Two files 
must also be renamed so that the implementation initial is removed. That is: 

i_TC_DRIVER.COM renames to TC_DRIVER.COM 

/ TEST _functional-unit . FOR renames to TEST _ functional-unit. FOR 

3) The files in step 1 , the implementation source code to be tested, should be compiled using 
the VAX FORTRAN compiler. No special compile switches are necessary, (e.g. FOR 
ASP.FOR) All object files should be placed in the same directory. 
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4) All files with ".FOR" extension fetched in step 2 should be compiled and object files placed 
in the same directory. Again no switches should be used. 

5) The i_LNKfunctional-unit.COM DCL command file fetched in step 2 above will link all 
the object files for a functional unit. The resulting executable will be placed in the [EXE] 
directory. Before using this link file, the file should be checked to ensure that the correct 
directory reference are used The following command should be initiated from the [LNK] 
directory: 

@i _LHLfunctional-unit.COM 

6) The test cases can actually be executed in this step by the entering the command given 
below. The command should be issued from the [TESTDRIVERS] directory. The 
command should be repeated for the number of test cases in the test suite for the functional 
unit. 

@TC_DRIVER functional-unit ttxxx 
where: functional-unit is replaced by the name of the functional unit 

tt is replaced by the test type (NR or RO) 

xxx is replaced by the test case number 

7) Once execution completes, the tester should look in the [US ER.TESTGA S Efunctional- 
unit. OUT] directory to see if any analysis files have been generated. If there are any, the 
tester should review them to see if a PR or SDCR should be initiated. 

8) The tester should maintain a record of test cases executed for each test subject. An 
example of the test log to be used is in section A. 10. A test log should be completed for 
tests on each functional unit. All test cases executed for a functional unit, structural or 
requirements-based, can be recorded on the same log. This is because any errors requiring 
code modification will require re-execution of all test cases for that functional unit. Listing 
all test cases in the same log will reduce the burden of identifying which test cases were re- 
executed The logs should be maintained for each implementation as the test history will 
vary depending on the errors discovered in the specific implementation. 

A.4.3 Subframe and Frame Test Case Execution Procedure 

After all functional units have been tested, the Verification Analyst can begin Integration 
Testing. This section describes the procedure for executing subframe and frame test cases on the 
VAX. According to the GCS Specification, each subframe must issue a call to the subroutine 
SimRendezvous, This will not be done in the test driver because Sim-Rendezvous is not in the 
scope of the GCS implementation. The order of operations for the subframe test stub is as 
follows: 

Load in the test data 
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Execute all functional units for the subframe 

Generate the expected value for the PACKET data element based on current test case values 
Compare all output with the expected results 


In order to run the Subframe tests new drivers and command files are created. The 
CLP_DRIVER.COM runs the Control Law Processing Subframe and SP_DRIVER.COM runs 
the Sensor Processing Subframe. The test execution procedure for frame and subframe cases is 
similar to the procedure described in the functional unit. The difference is in the specific files 
that must be Fetched. Table A. 1 should be referenced for specific file names for the subframe or 
frame test cases. Therefore, steps similar to the previous procedure will be condensed in the 
description below. 

1) Fetch the implementation’s source code and place them in the [IMPLEMENTATION] 
directory. 

2) Fetch the necessary test cases and place them in the appropriate subframe directories under 
the [TEST_CASES] directory. Place frame test cases in the [FRAME] directory. 

3) Fetch the support files as listed in Table A.l 1-1 for the desired subframe. Note that these 
files should be renamed to remove the implementation’s prefix. 

3) Compile and link all FORTRAN files as before 

4) The newly renamed LNKsubframe . CO M file should be used to build the executable for the 
test case. This step is identical to that for functional unit execution except the command is: 

@LNKsubframe 

5) The test cases can then be executed using the following command syntax 

@subframe_D RIVER xx 
for example: 

@CLP_DRIVER 001 
for frame test cases: 

@FRAME_DRIVER xx 

will run the CLP driver program using the CLP001.TC test- input and the expected-results 
file: CLP001.EX. The output (if any) will be in the analysis file. Note that if no analysis 
file is generated, then no error was found while executing the test suite. 

6) Again, the tester should check the OUT directory under the specific test case directory for 
any analysis files and determine if a PR or SDCR is necessary. 

7) Again, a test log should be completed with an entry for each test case run. The test log 
should show the disposition of each test case if errors are found. 
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A.4.4 Trajectory Test Case Execution Procedure 

The procedure for trajectory testing will differ from previous procedures because tests must be 

run with the simulator. Trajectory test procedure is divided into two parts. The first part builds 

an executable to run with the simulator. The second part actually runs the test cases. 

Procedure for linking the implementation to the simulator 

1) Fetch all files related to a specific implementation and place them in the 

[IMPLEMENTATION] directory along with the command file to build the 

implementation: 

/ BUILD. COM (Note that the /_ should be the initial of the 

implementation.) 

2) Also fetch the following simulator utility files and place them in the 

[IMPLEMENTATION] directory: 

GCSSIMRENDEZV OU S . OB J 
GCSSETUP.OBJ 
GCSWHOAMI.OBJ 
PAGEALIGN. OPT 

3) Build the implementation executable with the following command: 

@/_BUILD 

4) The implementation executable should be in the [.EXE] directory upon completion. The 
executable should be copied into the [TRAJ] directory for trajectory tests. 


Procedure for running trajectory > test cases 

1) Fetch the trajectory data, support and utility files from CMS and place them in the 
respective directories. 

(Files also listed in Table A.l 1-1) 


Data files 

(given below) 

[TRAJ.ATM] 
TRAJATMICxx.TC 
TRAJATMICxx.TC 
TRAJATMxx. SEED 

[TRAJ.TD] 
TRAJTDICxx.TC 
TRAJTDICxx.TC 
TRAJ TD xx. SEED 


! Support Files 

j [TRAJ] 

i_TRAJ.COM 
;i RUN TRAJ.COM 


; Utility Files 

j [TRAJ] 

; ACCURACY.DAT 
ALTERNATEACCURAC 
Y.DAT 

GCS_LIST.DAT 
GCS_SIM_S WITCHES. DA 
T 

;LIMITS.DAT 

:tabular_data.dat 
:traj sim.exe 
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2) Edit the GCS_LIST.DAT file by replacing the second line in the file with the name of the 
implementation’s executable to be tested. 

4) Execute test cases from the [TRAJ] directory with the command: 

@RUN_TRAJ 

The output files for trajectory test cases will be placed in the respective [OUT] directory. 

5) After executing all test cases, the VMS DIFFERENCE command should be used to 
compare the seed files in the respective [OUT] directories with those fetched from CMS. 

A.4.5 Structural Test Case Execution Procedure 

Structural test case execution procedure for both implementations are identical to functional 
unit test case execution. The file naming pattern is slightly different for each implementation. 
The specific names are given in Table A.2. The general procedure is as follows: 

1) If the executable for a functional unit has not been built at this point, then follow the 
procedure in functional unit test execution procedure steps 1 to 4 to build an executable. 

2) Fetch the structural test case from CMS. Refer to Table A.2 for specific names. Note 
that structural test case files should be placed in the same directory as those for functional 
unit tests. 

The Pluto implementation structural test cases have the following naming pattern: 
functional-unit _ PST_xcx.TC for test case input files 

functional-unit VST xxx.EX for expected results files 

The naming pattern for the Mercury structural test cases are: 

M Junctional-unit ST xxx.TC for test case input files 

M Junctional-unit _ST _xxx .EX for expected results files 

3) Fetch the support and utility files from CMS for the desired functional unit 

4) Execute structural test: 

For Pluto, the command to run the test cases is: 

“@TC_DRIVER functional-unit PST xxx” 

For Mercury, the command to run the test cases is: 

“@M_ST_DRIVER functional-unit xxx ” 
where the driver is given the name of the functional unit and the test case number. 
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A.5 DESIGN REVIEW CHECKLIST 


Process Structure 

1. Does the design clearly follow the data flow and control flow described in the specification? yes/no 

2. Does integration with the simulator follow the sequencing and implementation described in yes/no 
the specification? 

3. Does process sequencing comply with the functional unit scheduling as presented in Table yes/no 
4.3 in the specification? 

4. Do modules have high internal cohesion? 3 yes/no 

5. Do modules have low external coupling? 4 yes/no 

6. Are all module interfaces described? yes/no 

Data Usage 

1. Do the design data stores comply with those described in the specification's Data yes/no 

Requirements Dictionary Part II? 

2. Do the specified data in the design data dictionary conform to the specification's Data yes/no 

Requirements Dictionary Part I? 

3. If the design includes variables in addition to the global data store variables defined in the yes/no 
GCS specification, and these variables represent flows between processes, are they included 

in the design data dictionary? 

4. Do process inputs and outputs comply with the functional unit inputs and outputs in the yes/no 
specification? 

5. Are all inputs to processes used? yes/no 

6. Does each process modify only those global variables that are specified outputs for that yes/no 
process? 

7. Are all the input/output variables of a process defined in the INPUT/OUTPUT section of the yes/no 
design P-Spec for that process? 

Detail Requirements 

1 . Are sufficient algorithmic details given (including those not provided by the specification)? yes/no 

2. Are all specified logical conditions included in the design? yes/no 

3. Do logical conditions correctly use logical and relational operators? yes/no 

4. Are exceptional conditions anticipated and handled as described in the specification? yes/no 

Traceability 

1. Does the design satisfy all the functional requirements described in the specification? yes/no 

2. Can all parts of the design be traced back to the requirements? yes/no 


4 Coupling refers to the degree of interconnectedness between modules. 
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Clarity 


1. Is the overall function of each process described? yes/no 

2. Are assumptions documented? yes/no 

Compliance with Standards 

1. Are all derived requirements identified and justified? yes/no 

2. Was a successful balance check performed on the team work model of the design? yes/no 

3. Do the software design and the design documentation comply with the approved yes/no 

methodology and the design standards? 

A.6 CODE REVIEW CHECKLIST 

Data Usage 

1 . Are COMMON BLOCKS labeled with the same names as the global data stores defined in yes/no 
GCS Data Requirements Dictionary Part II? 

2. Do the variables in the COMMON BLOCKS use the same names and order as the variables yes/no 
in the global data stores defined in the GCS Data Requirements Dictionary Part II? 

3. Do the variables in the COMMON BLOCKS have the same data types, number of yes/no 

dimensions, and size of each dimension as specified in the GCS Data Requirements 

Dictionary Part I? 

4. If the code includes variables in addition to those defined in the global data stores in the yes/no 
GCS Data Requirements Dictionary Part II, are they defined, initialized, and used only 

within the scope of a subframe? 

5. Are references to array subscripts expressed in column, row order? yes/no 

6. Is array subscript usage within array bounds? yes/no 

7. Are constant values used only as constants and not as variables? yes/no 

8. Are DO loop index variables used only within the loop? yes/no 

9. Does the code maintain that same loop index within a loop? yes/no 

Structure 

1. Does the code comply with the software architecture from the design? yes/no 

2. Does the code avoid the use of GOTO statements? yes/no 

3. Do all the code's statements perform a clear function? yes/no 

4. Is the code void of any isolated or dead code segments? yes/no 


A-63 



Functions and Subroutines 


1 . Does each unit have a single function, and is it clearly described? yes/no 

2. Do actual and formal parameters agree in number, order, dimension, and data type? yes/no 

3. Are the functions of subroutine input and output parameters described? yes/no 

4. Are all the parameters passed to a subroutine used? yes/no 

5. Do the functions and subroutines return data of the correct type? yes/no 

6. Is there a call to GCSSIMRENDEZVOUS before each subframe? yes/no 

7. Are calls to GCS SIM RENDEZVOUS void of all parameters? yes/no 

8. Does the code avoid using system calls? yes/no 

Traceability 

1. Does the code satisfy all the requirements in the Requirements Traceability Matrix yes/no 

including all derived requirements? 

2. Do units map to a well-defined section in the Design? yes/no 

Logic 

1. Do logical conditions correctly use logical operators (.AND., .OR., .NOT.)? yes/no 

2. Do logical conditions correctly use relational operators (.GT., .GE., .LT., .LE., .EQ., .NE.)? yes/no 

3. Are all logical conditions included? yes/no 

4. Are comparisons of real variables to exact values avoided? yes/no 

5. Is loop nesting correct? yes/no 

6. Do loops have single exit and single entry points? yes/no 

Exceptional Conditions 

1. Is there code to detect the exceptional conditions listed in the Non-Functional section of the yes/no 
Requirements Traceability Matrix? 

2. If an exceptional condition is detected, does the code print the appropriate message to yes/no 

FORTRAN logical unit 6? 

Computations 

1 . Are mixed type mathematical expressions avoided? yes/no 

2. Do computations contain values with the same unit dimensions? yes/no 

3. Does the code avoid assigning real expressions to integers causing truncation? yes/no 

4. Are bit manipulations done correctly? yes/no 
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Compliance with Standards 


1. Does the code follow basic structured programming techniques? 

2. Does the software code and documentation comply with the approved code standards? 


yes/no 

yes/no 
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A.7 REQUIREMENTS TRACEABILITY MATRIX 


Functional Requirements 


DESIGN 


CODE TESTCASES 


0-1 Specify four separate, globally accessible data stores: 
EXTERNAL, 

GUIDANCESTATE, 
RUNPARAMETERS, and 
SENSOR OUTPUT. 


Control flow of the frame processin 


2-1.1 The appropriate control flow for a frame is: 

call to GCSSIMRENDEZVOUS. 

Satisfy the Sensor Processing subframe requirements (2-2). 
call to GCS SIM RENDEZVOUS. 

Satisfy Guidance Processing subframe requirements (2-3). 
call to GCS SIM RENDEZVOUS 

fulfill Control Law Processing subframe requirements (2-4) 
or terminate (2-1.2). 


2- 1 .2 The implementation is to terminate immediately upon completion of 

the Control Law Processing subframe requirements during the frame in which GP PHASE is 
set to 5. 


2-2.1 

Satisfy the TSP requirements (2.1.5) prior to fulfilling any of 

the other 

| requirements in (2.1.1 and 2.1.4). 


2-2.2 

Satisfy all requirements in the sensor processing 
requirements hierarchy (2.1). 


2-2.3 

Satisfy all requirements in the communications processing 

requirements 

| (2.4) upon satisfying 2-2.1. 


1 2-2.4 

Adhere to the functional unit scheduling in Table 4.3 of the 

GCS 

| specification. 


2-3 

The Guidance Processing subframe requirements. 


2-3.1 

Satisfy all requirements in the guidance processing 

requirements 

(2.2). 



2-3.2 

Satisfy all requirements in the communications processing 

requirements 

| (2.4) upon satisfying 2-3.1 . 


2-4 

The Control Law Processing subframe 
requirements. 


2-4.1 

Satisfy the AECLP requirements (2.3.1) prior to fulfilling any of the 1 

| CRCP requirements (2.3.3). 


1 2-4.2 

Satisfy all requirements in the control law processing 

requirements 

| hierarchy (2.3). 


1 2-4.3 

Satisfy all requirements in the communications processing 

requirements 

| (2.4) upon satisfying 2-4.1. 


1 2-4.4 

Adhere to the functional unit scheduling in Table 4.3 of the 

GCS 

| specification. 


2.1 

SP -- Sensor Processing 



ASP -- Accelerometer Sensor Processing 


2.1. 1-1 

Rotate variables. 


2.1. 1-2 

Adjust gain for temperature. 


2.1. 1-3 

Remove characteristic bias. 


2.1. 1-4 

Correct for misalignment. 


2.1. 1-5 

Determine Accelerations. 


2.1. 1-5.1 

Acceleration based on current A COUNTER. 


2.1. 1-5.2 

Acceleration based on mean of previous accelerations. 


2.1. 1-6 

Determine Accelerometer Status 


2.1. 1-6.1 

ASTATUS = healthy 


2. 1.1 -6.2 

ASTATUS = unhealthy 


2.1.2 

ARSP -- Altimeter Radar Sensor Processing 


2. 1.2-1 

Rotate variables. 


2. 1.2-2 

Determine altitude when echo is received, (based on 
ARCOUNTER) 


2. 1.2-3 

Determine altitude when echo is not received 


2. 1.2-3. 1 

Determine altitude based on third-order polynomial. 


2. 1.2-3 .2 

Determine altitude based on previous calculation. 


2. 1.2-4 

Set altimeter radar status. 


2.1. 2-4.1 

AR STATUS = healthy 


2.1. 2-4.2 

AR STATUS = failed 


2. 1.2-5 

Set values of K ALT. 
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2. 1.2-5 .2 

KALT = 0 



TDLRSP -- Touch Down Landing Radar Sensor 

Processing 

2. 1.3-1 

Rotate variables 


2. 1.3-2 

Determine state for each radar beam. 



2.1. 3-2.1 TDLR STATE = unlocked. 


2.1. 3-2.2 TDLR STATE = locked. 


2. 1.3-3 Determine Whether to set FRAME BEAM UNLOCKED 


2.1. 3-3.1 Set FRAME BEAM UNLOCKED to FRAME COUNTER 


2. 1 .3-3.2 Leave FRAME BEAM UNLOCKED unchanged 


2. 1 .3-4 Calculate the beam velocities 


2. 1 .3-5 Process beam velocities based on which beam(s) locked. 


2. 1 .3-5.1 no beams locked 


2.1. 3-5.2 Beaml locked 


2.1. 3-5.3 Beam2 locked 


2. 1.3-5 .4 Beam3 locked 


2. 1.3-5. 5 Beam4 locked 


2.1. 3-5.6 Beaml & Beam2 locked 


2.1. 3-5.7 Beaml & Beam3 locked 


2. 1.3-5. 8 Beaml & Beam4 locked 


2.1. 3-5.9 Beam2 & Beam3 locked 


2.1.3-5.10 Beam2 & Beam4 locked 


2.1.3-5.11 Beam3 & Beam4 locked 


2.1.3-5.12 Beaml, Beam2, & Beam3 locked 


2.1.3-5.13 Beaml, Beam2, & Beam4 locked 


2.1.3-5.14 Beaml, Beam3, & Beam4 locked 


2.1.3-5.15 Beam2, Beam3, & Beam4 locked 


2.1.3-5.16 Beaml, Beam2, Beam3, & Beam4 locked 


2. 1 .3-6 Convert to body velocities. 


2. 1 .3-7 Set values in K MATRIX. 


2. 1.3-7. 1 Kx = 0 


2.1. 3-7.2 Kx = 1 


2.1 .3-7.3 Ky = 0 


2.1. 3-7.4 Ky = 1 


2. 1.3-7. 5 Kz = 0 


2.1. 3-7.6 Kz = 1 


2. 1.3-8 Set TDLR STATUS. 


GSP -- Gvroscope Sensor Processin 


2. 1.4-1 

Rotate variables. 


2. 1.4-2 
axes. 

Determine the vehicle rotation rates along each of the 

vehicle's three 

2.1. 4-2.1 

Adjust gain. 


2.1. 4-2.2 

Convert G COUNTER. 


2. 1.4-3 

Set gyroscope status to healthy. 



.5 TSP -- Temperature Sensor Processing 


2. 1 .5- 1 Calculate solid state temperature 


2. 1 .5-2 Calculate Thermal Temperature 


2. 1 .5-3 Determine which Temperature to use (SS or Thermocouple) 


2. 1 .5-3 . 1 Calculate the Thermo sensor upper limit 


2. 1 .5-3.2 Calculate the Thermo sensor lower limit 


2. 1 .5-4 Determine Atmospheric Temperature 


2. 1 .5-5 Set status to healthy. 


2.1.6 TDSP — Touch Down Sensor Processing 


2. 1 .6- 1 Determine status of touch down sensor. 


2. 1 .6-2 Determine whether touch down has been sensed. 


2.2 GP — Guidance Processing 


2.2-1 Rotate variables. 


2.2-2 Determine the attitude, velocities, and altitude. 


2.2-2. 1 Set up the GP ROTATION matrix. 


2 . 2-22 Calculate new values of attitude, velocity, and 

altitude. 


2.2-3 Determine if the engines should be on or off. 


2.2-3. 1 Engines on 


.2 Engines off 


Set FRAME ENGINES IGNITED 


2.2-5 Determine velocity error. 


2.2-6 Determine optimal velocity 


2.2-7 Determine if contour has been crossed. 


2.2-8 Determine guidance phase. 


2.2-8. 1 GP PHASE =1 


2.2-8.2 GP PHASE = 2 


GP PHASE = 3 


GP PHASE = 4 
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A.8 SAMPLE REVIEW LOG FORM 


Individual Inspection Preparation Log Page 1 of 

Name: Date Log Submitted: 

Implementation: Date of Inspection: 

Role: o Reader o Recorder 

o Moderator o Inspector 

Defects/Clarity Problems/Concerns 

Location of Concern Description of the problem 

(i.e. module name/P-Spec #, 
page number, etc.) 


The Moderator needs to have this completed fonn at least 4 hours before the scheduled Inspection session. 
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Individual Inspection Preparation Log 


Page of 


Defects/Clarity Problems/Concerns 

Location Description of the problem 
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A.9 GCS Equivalence Classes 


This section gives the equivalence classes used for testing GCS implementations. Two tables 
are include to allow cross referencing of equivalence class to test cases. Table A.9-1, GCS 
Equivalence Classes, lists all the variables that have equivalent classes. These do not include 
variables in the REJNPARAMETER data store. Also, as stated previously, variables defined as 
integers but used as enumerated types are not considered testable with equivalence classes. 
Finally, variables that are outputs to the GCS simulator are not tested. The GCS Equivalence 
Class Table gives the variable name, its type, its limits as defined in the GCS Specification, and 
the equivalence classes defined for that variable. Table A.9-1 also associates an equivalence class 
name with each class definition. This name is used in Table A.9-2 to test cases with the 
equivalence class. The equivalence class names are derived from the variable name with an 
arbitrary number extension. The names do not imply whether the class is valid or invalid. That 
can be readily determined by reviewing the variable’s limits; typically, the first one listed is the 
valid equivalence class. The following abbreviations are used in Table A.9-1 to represent 
FORTRAN Type definition: 

R8 - REAL* 8 12 - INTEGER*2 

LI- LOGICAL* 1 14- INTEGER*4 

Table A.9-1 : GCS Equivalence Classes 


VARIABLE NAME 

TYPE 

Limits 

Equivalence Class Definitions 

Equivalence Class Name 

AACCELERATION 

R8 

[-20., 

5.] 

-20. < A ACCELERATION < 5 
A ACCELERATION > 5. 

A ACCELERATION < -20. 

AACCELERATION. 1 
AACCELERATION.2 
AACCELERATION.3 

ACOUNTER 

12 

[0, 

(2 1 5 )- 1 ] 

0 < A COUNTER < (2 15 )-1 

A_C0UNTER>(2 15 )-1 
A COUNTER < 0 

ACOUNTER. 1 
ACOUNTER.2 
ACOUNTER.3 

ASTATUS 

LI 

0=HEALTHY 

1=UNHEALTH 

Y 

HEALTHY 

UNHEALTHY 

INVALID 

ASTATUS.l 

ASTATUS.2 

ASTATUS.3 

ARALTITUDE 

R8 

[0., 

2000.] 

0. < AR ALTITUDE < 2000. 
AR ALTITUDE > 2000. 

AR ALTITUDE < 0 

ARALTITUDE. 1 
ARALTITUDE.2 
ARALTITUDE.3 

AR COUNTER 

12 

[-h 

(2 15 )-1] 

-1< AR COUNTER < (2 15 )-1 
AR COUNTER > (2 1 5 )- 1 
AR COUNTER < -I 

AR COUNTER. 1 
AR COUNTER.2 
AR COUNTER.3 

ARSTATUS 

LI 

0=HEALTHY 
1=F AILED 

HEALTHY 

FAILED 

INVALID 

ARSTATUS.l 

ARSTATUS.2 

ARSTATUS.3 

ATMOSPHERIC TE 
MP 

R8 


-200. < ATMOSPHERICTEMP < 25. 
ATMOSPHERICTEMP > 25. 
ATMOSPHERIC TEMP < -200. 

ATMOSPHERICTEMP. 1 
ATMOSPHERICTEMP.2 
ATMOSPHERICTEMP.3 

FRAME_BEAM_ 

UNLOCKED 

14 

[0. 

(2 3 1 )- 1 ] 

0 < FRAMEBEAMUNLOCKED < (2 3 1 )- 1 

FRAMEBEAMUNLOCKED > (2 3 1 )- 1 
FRAME BEAM UNLOCKED < 0 

FRAMEBEAMUNLOCKED. 1 
FRAME_BEAM_UNLOCKED.2 
FRAMEBEAMUNLOCKED.3 

FRAME COUNTER 

14 

[1. 

(2 3 1 )- 1 ] 

1 < FRAME COUNTER £ (2 3 1 )- 1 
FRAME COUNTER > (2 31 )-1 
FRAME COUNTER < 1 

FRAME COUNTER. 1 
FRAME COUNTER.2 
FRAME COUNTER.3 
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Table A.9-1: (Continued) 


VARIABLE 

NAME 

TYPE 

Limits 

Equivalence Class Definitions 

Equivalence Class Name 

FRAME_ENGINES_ 

IGNITED 

14 

[1, 

(2 31 )-!] 

1 < FRAME ENGINES IGNITED < (2 31 )-1 
FRAMEENGINESIGNITED > (2 31 )-1 
FRAMEENGINESIGNITED < 1 

FRAME ENGINES IGNITED. 1 
FRAMEENGINESIGNITED.2 
FRAMEENGINESIGNITED.3 

G COUNTER 

12 

[-(2 14 -b, 

2 14 -1] 

-((2 14 ) -1) < G COUNTER < (2 14 )-1 
GCOUNTER > (2 14 )-1 
GCOUNTER < -((2 14 ) -1) 

G COUNTER. 1 
GCOUNTER.2 
G COUNTER. 3 

G ROTATION 

R8 

[-1.0, 

1.0] 

-l.< G ROTATION < -P4 
-P4 < GROTATION < -P3 
-P3 < G ROTATION < -P2 
-P2 < G ROTATION < -PI 
-PI < G ROTATION < 0 
0 < G ROTATION < PI 
PI < G ROTATION < P2 
P2 < G ROTATION < P3 
P3 < G ROTATION < P4 
P4 < G ROTATION < 1 
G ROTATION > 1 
G ROTATION <-l 

G ROTATION. 1 
G ROTATIONS 
G ROTATION. 3 
G ROTATIONS 
G ROTATIONS 
G ROTATION. 6 
G ROTATION. 7 
G ROTATION. 8 
G ROTATION. 9 
G ROTATION. 10 
G ROTATION. 11 
GROTATION. 12 

GP ALTITUDE 

R8 

[0., 

2000.] 

0< GPALTITUDE < ENGINESONALTITUDE 
ENGINES ON ALTITUDE. < GP ALTITUDE < 
2000 

GP ALTITUDE > 2000 
GP ALTITUDE < 0 

GPALTITUDE. 1 

GPALTITUDE.2 

GP ALTITUDE.3 
GP ALTITUDE.4 

GP ATTITUDE 

R8 

[-1..L] 

-1. < GP ATTITUDE <1. 
GP ATTITUDE > 1. 

GP ATTITUDE <-l. 

GP ATTITUDE. 1 
GP ATTITUDE.2 
GPATTITUDE.3 

GP ROTATION 

R8 

[-U-] 

-1. < GP ROTATION(ij) < 1. 
GP ROTATION(ij) > 1. 

GP ROTATION(ij) > -1. 

GP ROTATION. 1 
GP ROTATIONS 
GP ROTATIONS 

GPVELOCITY 

R8 

[-100., 

100.] 

-100. < GP VELOCITY (I) < 100. 
GP VELOCITY > 100. 

GP VELOCITY <-100. 

GP VELOCITY. 1 
GP VELOCITY.2 
GP VELOCITY.3 

INTERNALCMD 

R8 

[-■7, 

1.7] 

-.7 < INTERNAL CMD < 0 
0 £ INTERNAL CMD < 1.0 
1 .0 < INTERNAL CMD <1.7 
INTERNAL CMD > 1.7 
INTERNAL CMD < -.7 

INTERNAL CMD.l 
INTERNAL CMD. 2 
INTERNAL CMD. 3 
INTERNAL CMD.4 
INTERN ALCMD. 5 

PE INTEGRAL 

R8 

[-100., 

100.] 

-100 < PE INTEGRAL < 100. 
PE INTEGRAL > 100. 

PE INTEGRAL <-100. 

PE INTEGRAL. 1 
PE INTEGRALS 
PE INTEGRALS 

SSTEMP 

12 

[0, 

(2 15 )-1] 

M3 - 0. 1 5L < SS TEMP < M4 + 0. 1 5L 
0 < SS TEMP < M3 - 0.15L 
M4 + 0.15L < SS TEMP < (2 15 )-1 
SS TEMP>(2 15 )-1 
SS TEMP < 0 

SS TEMPT 
SS TEMP.2 
SS TEMP.3 
SS TEMP.4 
SSTEMP.5 

TD COUNTER 

12 

[-2 15 , 

(2 15 )-!] 

TD COUNTER = 0 
TD COUNTER = -1 
-2 15 <TD COUNTER <(2 15 )-1 

TD COUNTER. 1 
TD COUNTER.2 
TD COUNTER.3 

TDLRCOUNTER 

12 

[0, 

(2 15 )-1] 

0 < TDLR COUNTER < (2 15 )-1 
TDLR COUNTER >(2 15 )-1 
TDLR COUNTER < 0 

TDLR COUNTER. 1 
TDLR COUNTER.2 
TDLR COUNTER.3 

TDLRSTATE 

LI 

0=UNLOCKED 

l=LOCKED 

BEAM UNLOCKED 
BEAM LOCKED 
INVALID 

TDLR STATE. 1 
TDLR STATE.2 
TDLR STATE.3 

TDLR VELOCITY 

R8 

[-100., 

100.] 

-100< TDLR VELOCITY < 100. 
TDLR VELOCITY > 100. 
TDLR VELOCITY <-100. 

TDLR VELOCITY. 1 
TDLR VELOCITY.2 
TDLR VELOCITY.3 
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TDSSTATUS 

LI 

0=HEALTHY 
1=F AILED 

HEALTHY 

FAILED 

INVALID 

TDS STATUS. 1 
TDS STATUS.2 
TDS STATUS. 3 

TE INTEGRAL 

R8 

[-100., 

-100. <TE INTEGRAL < 100. 

TE INTEGRAL. 1 



100.] 

TE INTEGRAL > 100. 

TE INTEGRALS 




TE INTEGRAL <-100. 

TEINTEGRAL.3 

TE_LIMIT 

R8 

[-100., 

-100. < TELIMIT < TEMIN 

TE LIMIT. 1 



100.] 

TEMIN < TE LIMIT < TEMAX 

TE LIMIT. 2 




TE MAX < TE LIMIT <100. 

TE LIMIT.3 




TE LIMIT > 100. 

TE LIMIT. 4 




TE LIMIT <-100. 

TELIMIT.5 

THERMOTEMP 

12 

[0, 

M3 < THERMO TEMP < M4 

THERMO TEMP. 1 



(2 15 )-1] 

M3 - 0. 1 5L < THERMO TEMP < M3 

THERMO TEMP. 2 




M4 < THERMO TEMP < M4 + 0. 1 5L 

THERMO TEMP. 3 




0 < THERMO TEMP < M3 - 0.15L 

THERMO TEMP. 4 




M4 + 0.15L < THERMO TEMP < (2 15 )-1 

THERMO TEMP. 5 





THERMO TEMP. 6 




THERMO TEMP>(2 15 )-1 

THERMOTEMP.7 




THERMO TEMP < 0 


THETA 

R8 

[-P.P] 

-p < THETA < -THETA2 

THETA. 1 




-THETA2 < THETA < -THETA 1 

THETA.2 




-THETA 1 < THETA <0 

THETA.3 




0 < THETA < THETA 1 

THETA.4 




THETA 1 < THETA < THETA2 

THETA.5 




THETA2 < THETA < p 

THETA.6 




THETA > p 

THETA. 7 




THETA < -p 

THETA. 8 

VELOCITY ERROR 

R8 

[-300., 

-300. < VELOCITY ERROR < 20. 

VELOCITY ERROR. 1 



20.] 

VELOCITY ERROR >20. 

VELOCITY ERROR.2 




VELOCITY ERROR < -300. 

VELOCITY ERROR.3 

YE INTEGRAL 

R8 

[-100., 

-100. < YE INTEGRAL < 100. 

YE INTEGRAL. 1 



100.] 

YE INTEGRAL > 100. 

YE INTEGRALS 




YE INTEGRAL <-100. 

YE INTEGRALS 


A-73 




































Table A. 9-2 : List of Test Cases by Equivalence Class Name 


Equivalence Class Name 

A ACCELERATION.! 


A ACCELERATIONS 


A ACCELERATIONS 


A COUNTERS 
\ CO! \ I I R 2 
ACOUNTER.3 
A STATUS. 1 
ASTATUS.2 
ASTATUS.3 
ARALTITUDE. 1 

ARALTITUDE.2 

ARALTITUDE.3 

AR COUNTERS 

ARCOUNTER.2 

ARCOUNTER.3 

ARSTATUS.l 

ARSTATUS.2 

ARSTATUS.3 

ATMOSPHERICTEMP. 1 

ATMOSPHERICTEMP.2 

ATMOSPHERICTEMP.3 

FRAMEBEAMUNLOCKED. 1 

FRAMEBEAMUNLOCKED.2 
FRAMEBEAMUNLOCKED.3 
FRAME COUNTERS 

FRAME COUNTERS 
FRAME COUNTERS 
FRAMEENGINES IGNITED. 1 

FRAMEENGINESIGNITED.2 
FRAMEENGINESIGNITED.3 
GCOUNTER. 1 
GCOUNTER.2 
GCOUNTER.3 
G ROTATION. 1 
G ROTATIONS 


Test case(s) 

AECLPNR001--012.TC, 

GPNR 001— 008.TC, 

ASP NR 001.TC, ASP NR 002.TC 
AECLP RO 038.TC, 

GP RO 012.TC, GP RO 014.TC, GP RO 016.TC, GP RO 018.TC, GP RO 020.TC, 

GP RO 022.TC, GP RO 024.TC, GP RO 026.TC, GP RO 028.TC, 

ASP RO 018.TC, ASP R0 020.TC, ASP RO 022.TC, ASP RO 024.TC, ASP RO 026.TC, 

ASP RO 028.TC, ASP RO 030.TC, ASP RO 032.TC, ASP RO 034.TC, ASP RO 036.TC, 

ASP RO 038.TC, ASP RO 040.TC 

AECLP RO 037.TC, 

GP RO 01 l.TC, GP RO 013.TC, GP RO 015.TC, GP RO 017.TC, GP RO 019.TC, 

GP RO 021.TC, GP RO 023.TC, GP RO 025.TC, GP RO 027.TC, 

ASP RO 017.TC, ASP RO 019.TC, ASP RO 02 l.TC, ASP RO 023.TC, ASP RO 025.TC, 

ASP RO 027.TC, ASP RO 029.TC, ASP RO 03 1 .TC, ASP RO 033.TC, ASP RO 035.TC, 

ASP RO 037.TC, ASP RO 039.TC 

ASP NR 001.TC, ASP NR 003.TC, ASP NR 016.TC 

ASPRO013 — 015. TC 

ASPROOIO — 012.TC 
ASPNR00 1 .TC 
ASP NR 003 - 005. TC 
ASP RO 041 - 049.TC 
GPNR 001— 008.TC 

ARSP NR 01 l.TC, ARSP NR 016.TC, ARSP NR 0 1 7.TC 
GP RO 048.TC, GP R0 050.TC, GP RO 052.TC, 

ARSP RO 007 - 010.TC 

GP RO 047.TC, GP RO 049.TC, GP RO 05 l.TC 
ARSP RO 003 - 006.TC 

ARSP NR 01 l.TC, ARSP NR 016.TC, ARSP NR 0 1 7.TC, ARSP NR 022.TC, 

ARSPNR 023.TC, 

ARSP RO 00 l.TC _ " 

ARSP RO 002.TC 

ARSP NR 0 1 1 .TC, ARSP NR 016.TC, ARSP NR 0 1 7.TC 

ARSPNR012 — 015.TC 

ARSP RO 018 - 02 l.TC 

ASPNR001.TC 

GSP NR 00 l.TC 

ASPR0 009.TC 

GSP RO 003.TC 

ASPR0 008.TC 

GSP RO 002.TC 

TDLRSP NR 001.TC, TDLRSP NR 003.TC, TDLRSP NR 005.TC, 

TDLRSP NR 007 - 02 l.TC, 

TDLRSP RO 022.TC 
TDLRSP RO 023.TC 

TDLRSP NR 00 1 .TC, TDLRSP NR 003.TC, TDLRSP NR 005.TC, 

TDLRSP NR 007 - 02 l.TC 
TDLRSP RO 024.TC 
TDLRSP RO 025.TC 
GP NR 001-008.TC, GP NR 053.TC, 

AECLPNR00 1 -0 1 2.TC 
AECLP RO 056.TC 
AECLPRO 057.TC 
GSP NR 001.TC 
GSP R0 007 - 009.TC 
GSP R0 004 - 006. TC 
RECLPNR 046, 056-058, 068.TC 
RECLP_NR_039,040,048.TC 
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Table A. 9-2 : (Continued) 


Equivalence Class Name 

Test case(s) 

G ROTATION. 3 

RECLP NR 0 15-0 1 7.TC 

RECLPNR 020, 03 1,032, 036, 038, 050, 055.TC 

G ROTATIONS 

RECLPNR 023— 026,033.TC 

G ROTATION. 5 

AECLPNR 005--007.TC, AECLP NR 01 1-012.TC 
GP NR 005-008.TC 
RECLPNR 003— 006,01 1,012. TC 

G ROTATION. 6 

AECLP NR 00 1 -004.TC, AECLP_NR_008,0 1 0.TC 
GP NR 001-008.TC 

RECLP NR 001-059.TC, RECLP NR 064-067.TC 

G ROTATION. 7 

RECLP_NR_022,027,028,034.TC 

G ROTATION. 8 

AECLPNR 004.0 1 0.TC 
GP NR 001-004.TC 
RECLPNR0 13,0 14,0 1 8,0 19.TC 
RECLPNR 021, 029, 030,035, 037.TC 

G ROTATION. 9 

GP NR 002-004.TC 

RECLP NR 0 1 0.TC, RECLP NR 041 -044.TC, 
RECLP_NR_047,049,05 1 .TC 

G ROTATION. 10 

AECLPNR 005-007.TC 
GP NR 001.TC 

RECLP NR 001-059.TC, RECLP NR 064-067.TC 

G ROTATION.il 

RECLP RO 060.TC, 

GP RO 069-07 l.TC, GP RO 075-077.TC, GP RO 08 1-083. TC 

G ROTATION. 12 

RECLP RO 061. TC, 

GP RO 066-068.TC, GP RO 072-074.TC, GP R0 078-080.TC 

GP ALTITUDE. 1 

AECLPNROO 1 -0 1 2.TC, 
GP NR 001-008.TC 

GP ALTITUDE.2 

AECLPRO 039, 040, 042,044, 045, 047.TC 

GP ALTITUDE.3 

AECLP RO 01 4.TC, 
GP RO 010.TC 

GP ALTITUDE.4 

AECLP RO 013. TC, 
GP RO 009.TC 

GP ATTITUDE. 1 

AECLPNROO 1 -0 1 2.TC, 
GP NR 001-008.TC 

GP ATTITUDE.2 

AECLP RO 01 6.TC, 

GP RO 029.TC, GP RO 03 l.TC, GP RO 033.TC, GP RO 035. TC, GP RO 037.TC, 
GP RO 039.TC, GP RO 041.TC, GP RO 043.TC, GP RO 045.TC 

GP ATTITUDE. 3 

AECLP RO 01 5.TC, 

GP RO 030.TC, GP RO 032.TC, GP RO.034 TC, GP RO 036. TC, GP RO 038.TC, 
GP RO 040.TC, GP RO 042.TC, GP RO 044.TC, GP RO 046.TC 

GP ROTATION. 1 

AECLP NR OO 1 -0 1 2 .TC, 
GP NR 001-008.TC 

GP ROTATIONS 

AECLP RO 018.TC, AECLP R0 020.TC 

GP ROTATION.3 

AECLP RO 0 1 7.TC, AECLP RO 0 1 9.TC 

GP VELOCITY. 1 

AECLPNROO 1 -0 1 2.TC, 
GP NR 001-008.TC 

GP VEL0CITY.2 

AECLP R0 022.TC, AECLP RO 024.TC, AECLP RO 026.TC, 

GP RO 055.TC, GP RO 057.TC, GP RO 059.TC, GP RO 60.TC, GP RO 062.TC, 
GP RO 064.TC 

GP VEL0CITY.3 

AECLP RO 02 1 .TC, AECLP RO 023.TC, AECLP R0 025.TC, 

GP RO 054.TC, GP RO 056.TC, GP RO 058.TC, GP RO 061.TC, GP RO 63.TC, GP RO 65.TC 

INTERN ALCMD.l 

AECLP_NR_004,008,009.TC 

INTERN ALCMD.2 

AECLP NR 001 -007.TC 

INTERN ALCMD. 3 

AECLP NR 055.TC 

INTERN ALCMD.4 

AECLP RO 049.TC, AECLP RO 05 l.TC, AECLP RO 053.TC 

INTERN ALCMD. 5 

AECLP RO 048.TC, AECLP R0 050.TC, AECLP RO 052.TC 

PE INTEGRAL. 1 

AECLPNROO 1 -0 1 2.TC 

PE INTEGRALS 

AECLP RO 028.TC 
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Table A. 9-2 : (Continued) 


Equivalence Class Name 

Test case(s) 

PE INTEGRALS 

AECLP RO 027.TC 

SSTEMP.l 

TSP NR 001.TC 

SSTEMP.2 

TSP NR 002.TC 

SSTEMP.3 

TSP NR 003. TC 

SSTEMP.4 

TSP RO 004.TC 

SSTEMP.5 

TSP RO 005. TC 

TD COUNTER. 1 

TDSP NR 001.TC 

TD COUNTER.2 

TDSP NR 002.TC 

TD COUNTER.3 

TDSP NR 003. TC 

TDLR COUNTER. 1 

TDLRSP NR 001.TC, TDLRSP NR 003.TC, TDLRSP NR 005.TC, 
TDLRSP NR 007 - 021.TC, 

TDLR COUNTER.2 

TDLRSP RO 028.TC 

TDLR COUNTER.3 

TDLRSP RO 027.TC 

TDLR STATE. 1 

TDLRSP NR 00 1 .TC, TDLRSP NR 007 - 021.TC, 

TDLR STATE.2 

TDLRSP NR 005. TC, TDLRSP NR 007 - 021.TC, 

TDLR STATE.3 

TDLRSP RO 026.TC 

TDLR VELOCITY. 1 

GPNR 001— 008.TC 

TDLR VELOCITY.2 

GP RO 085.TC, GP RO 087.TC, GP RO 089.TC, GP RO 091.TC, GP RO 093.TC, 
GP RO 095.TC, GP RO 097.TC, GP RO 099.TC, GP RO 101.TC 

TDLR VELOCITY.3 

GP RO 084.TC, GP RO 086. TC, GP RO 088.TC, GP RO 090.TC, GP RO 092.TC, 
GP RO 094.TC, GP RO 096.TC, GP RO 098.TC, GP RO 100.TC 

TDS STATUS. 1 

TDSP NR 001 - 003. TC 

TDS STATUS.2 

TDSP NR 004 - 006. TC 

TDS STATUS.3 

TDSP R0 007.TC 

TE INTEGRAL. 1 

AECLPNR00 1 -0 1 2.TC 

TEINTEGRAL.2 

AECLPRO30.TC 

TEINTEGRAL . 3 

AECLPRO 029.TC 

TE LIMIT. 1 

AECLP NR 005.TC, AECLP_RO_029,033.TC 

TE LIMIT.2 

AECLPNR 006-009.TC 

TE LIMIT.3 

AECLP RO 030,034.TC 

TE LIMIT.4 

AECLPRO 032.TC 

TE LIMIT.5 

AECLPRO03 1 .TC 

THERMO TEMP. 1 

TSPNR00 1 .TC 

THERMOTEMP .2 

TSPNR 006.TC 

THERMO TEMP.3 

TSPNR 007.TC 

THERMO TEMP .4 

TSPNR 008.TC 

THERMO JTEMP.5 

TSPNR 009.TC 

THERMO TEMP.6 

TSP R0 010.TC 

THERMO TEMP.7 

TSP RO 011.TC 

THETA. 1 

RECLP NR 0 1 0,0 1 1 ,0 19,020,027,034,035,037.TC 
RECLP_NR_040,04 1,046, 048, 050-054, 066.TC 

THETA.2 

RECLP_NR_006,007,026,030,03 1 .TC 

THETA.3 

RECLPNR 002, 003, 014,0 1 5,022,023,054,059.TC 
RECLP NR 064.TC 

THETA.4 

RECLP NR 00 1 ,004,0 13,0 1 6,02 1 ,024, 065,068. TC 

THETA.5 

RECLP_NR_005,008,028,029.TC 

THETA.6 

RECLP NR 009,0 1 2,0 1 7,0 1 8,025,032,033,036.TC 
RECLPNR 038, 039, 042-045, 047,049, 055-058.TC 
RECLP NR 067.TC 

THETA. 7 

RECLP RO 062.TC 

THETA.8 

RECLP RO.063.TC 

VELOCITY ERROR. 1 

AECLPNR00 1 -0 1 2.TC 

VELOCITY ERROR.2 

AECLP RO 034.TC 

VELOCITY ERROR.3 

AECLP RO 033.TC 

YEJNTEGRAL.l 

AECLP NR 00 1 -0 1 2.TC 

YEINTEGRAL.2 

AECLP RO 036.TC 

YEINTEGRAL.3 

AECLP RO 035.TC 
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A.10 Traceability Matrix For Requirements-based Test Cases 


Table A. 10-1 is the Traceability Matrix with Requirements test cases filled in. It gives a 
detailed listing of the GCS requirements and gives the test cases that test those requirements. 
Note that cases listed fall into the normal range category as defined by DO-178B because they 
verify that the software functions according to the GCS Specification. Since these cases are 
requirements-based, this table is identical for both the Mercury and Pluto implementations. 
Hence the information is placed here instead of in the results document. 


Table A. 10-1 : Traceability Matrix with Requirements -based Test cases 


Functional Requirements 

TESTCASE NAME 

0-1 Specify four separate, globally accessible data stores: 
EXTERNAL, 

GUIDANCESTATE, 

RUN PARAMETERS, and 
SEN SOROUTPUT. 

All Test Cases 


Control flow of the frame processing. 


2-1.1 

The appropriate control flow for a frame is: 

1) call to GCS_SIM RENDEZVOUS. 

2) Satisfy the Sensor Processing subframe requirements (2-2). 

3) Call to GCS_SIM RENDEZVOUS. 

4) Satisfy Guidance Processing subframe requirements (2-3). 

5) Call to GCS_SIM RENDEZVOUS 

6) Satisfy Control Law Processing subframe requirements (2-4) 

7) Terminate if GP PHASE = 5 (2-1.2). 

FRAME 00 1-009. TC 

2-1. 1-1 

GP PHASE transition from 1 to 2 

FRAME001.TC 

2-1. 1-2 

GP PHASE = 2, just before AE JTEMP transition 

FRAME 002. TC 

2-1. 1-3 

AE TEMP transitions from WARM to HOT and CHUTE RELEASED 
transitions from 0 to 1 

FRAME 003. TC 

2-1. 1-4 

GP PHASE transitions from 2 to 3 

FRAME 004.TC 

2-1. 1-5 

CONTOUR CROSSED transitions from 0 to 1 

FRAME 005. TC 

2-1. 1-6 

Frame after CONTOUR CROSSED transitions 

FRAME 006.TC 

2-1. 1-7 

CL = 2 

FRAME 007.TC 

2-1. 1-8 

GP PHASE transitions from 3 to 4 

FRAME 008. TC 

2-1.2 

The implementation is to terminate immediately upon completion of 

FRAME 009. TC 

the Control Law Processing subframe requirements during the frame in 


which GP PHASE is set to 5. 


2-2 

Sensor Processing subframe requirements. 


2-2.1 

Satisfy the TSP requirements (2.1.5) prior to fulfilling any of the 
other requirements in (2.1.1 and 2.1.4). 

SP001.TC 

2-2.2 

Satisfy all requirements in the sensor processing requirements 
hierarchy (2.1). 

SP001.TC 

2-2.3 

Satisfy all requirements in the communications processing 
requirements (2.4) upon satisfying 2-2.1. 

SP001.TC 

2-2.4 

Adhere to the functional unit scheduling in Table 4.3 of the GCS 
specification. 

SP001.TC 


The Guidance Processing subframe requirements. 


2-3.1 

Satisfy all requirements in the guidance processing requirements 
(2.2). 

GPSF 00 1-008. TC 
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2-3.2 Satisfy all requirements in the communications processing 
requirements (2.4) upon satisfying 2-3.1. 


The Control Law Processing subframe requirements. 


2-4.1 Satisfy the AECLP requirements (2.3.1) prior to fulfilling any of the 
CRCP requirements (2.3.3). 


2-4.2 Satisfy all requirements in the control law processing requirements 
hierarchy (2.3). 


2-4.3 Satisfy all requirements in the communications processing 
requirements (2.4) upon satisfying 2-4.1. 


2-4.4 Adhere to the functional unit scheduling in Table 4.3 of the GCS 
specification. 


SP -- Sensor Processing 


ASP -- Accelerometer Sensor Processing 


2. 1.1-1 Rotate variables. 


2. 1.1-2 Adjust gain for temperature. 


2 . 1 . 1 -3 Remove characteristic bias . 


2. 1 . 1 -4 Correct for misalignment. 


2 . 1 . 1 -5 Detennine Accelerations . 


2. 1.1 -5.1 Acceleration based on current ACOUNTER. 


2.1. 1-5.2 Acceleration based on mean of previous accelerations. 


2 . 1 . 1 -6 Detennine Accelerometer Status 


2 . 1 . 1 -6 . 1 A JSTATUS = healthy 


2. 1.1 -6. 2 A_STATUS = unhealthy 


.2 ARSP — Altimeter Radar Sensor Processing 


2 . 1 .2- 1 Rotate variables . 


2. 1 .2-2 Detennine altitude when echo is received, (based on AR COUNTER) 


2.1 .2-3 Detennine altitude when echo is not received 


2.1 .2-3. 1 Detennine altitude based on third-order polynomial. 


2. 1.2-3. 2 Detennine altitude based on previous calculation. 


2 . 1 .2-4 Set altimeter radar status . 


2 . 1 .2-4 . 1 AR STATUS = healthy 


2.1. 2-4.2 AR STATUS = failed 


2. 1.2-5 Set values of K ALT. 


2.1. 2-5.1 K ALT = 1 


2. 1.2-5 .2 K ALT = 0 


TDLRSP — Touch Down Landing Radar Sensor Pi 


2. 1.3-1 Rotate variables 


2.1 .3-2 Detennine state for each radar beam. 


2.1 .3-2.1 TDLR STATE = unlocked. 


2. 1.3-2. 2 TDLR STATE = locked. 


2.1 .3-3 Determine Whether to set FRAMEBEAMUNLOCKED 


2.1. 3-3.1 Set FRAME BEAM UNLOCKED to FRAME COUNTER 


2.1.3-3.2 Leave FRAME BEAM UNLOCKED unchanged 


2.1 .3-4 Calculate the beam velocities 


2.1 .3-5 Process beam velocities based on which beam(s) locked. 


GPSF 00 1-008. TC 


CLP 001-014. TC 


CLP 001-014. TC 


CLP 001-014. TC 


CLP 001-014. TC 


ASP NR 006-007.TC 


ASP NR 001-005.TC 


ASP NR 001-005.TC 


ASP NR 001-005. TC 


ASP NR 001.TC, 
ASP NR 003-005. TC 


ASP NR 002.TC 


ASP NR 001 .TC 


ASP NR 002.TC 


ARSP NR 022-023.TC 


ARSP NR 016. TC, 
ARSP NR 017. TC, 
ARSP NR 022. TC 


ARSP NR 01 l.TC 


ARSP NR 012-015. TC 


ARSP NR 022.TC 


ARSP NR 01 l.TC, 
ARSP NR 012. TC 


ARSP NR 01 l.TC 


ARSP NR 012-015. TC 


Processing 



TDLRSP NR 005.TC 


TDLRSP NR 00 l.TC 


TDLRSP NR 003.TC, 
TDLRSP NR 005.TC 


TDLRSP NR 00 l.TC 


TDLRSP NR 00 l.TC 
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2. 1.3- 5. 1 no beams locked 

2.1.3- 5.2 Beaml locked 

2. 1.3- 5. 3 Beam2 locked 

2.1.3- 5.4 Beam3 locked 

2. 1.3- 5. 5 Beam4 locked 

2. 1.3- 5. 6 Beaml & Beam2 locked 

2. 1.3- 5. 7 Beaml & Beam3 locked 

2. 1.3- 5. 8 Beaml & Beam4 locked 

2.1. 3- 5.9 Beam2 & Beam3 locked 

2.1.3- 5.10 Beam2 & Beam4 locked 

2.1. 3- 5.1 1 Beam3 & Beam4 locked 

2.1.3- 5.12 Beaml, Beam2, & Beam3 locked 

2.1.3- 5.13 Beaml, Beam2, & Beam4 locked 

2.1.3- 5.14 Beaml, Beam3, & Beam4 locked 

2.1.3- 5.15 Beam2, Beam3, & Beam4 locked 

2.1.3- 5.16 Beaml, Beam2, Beam3, & Beam4 locked 

2. 1.3- 6 Convert to body velocities. 

2.1 .3- 7 Set values in K MATRIX. 

2. 1.3- 7. 1 Kx = 0 

2.1. 3- 7.2 Kx = 1 

2.1. 3- 7.3 Ky = 0 

2.1. 3- 7.4 Ky = 1 

2. 1.3- 7. 5 Kz = 0 

2.1. 3- 7.6 Kz = 1 

2. 1.3- 8 Set TDLR STATUS. 

2.1.4 GSP -- Gyroscope Sensor Processing 

2. 1.4- 1 Rotate variables. 

2.1 .4- 2 Determine the vehicle rotation rates along each of the vehicle's 


three axes. 

2. 1.4- 2. 1 Adjust gain. 

2. 1.4- 2. 2 Convert G COUNTER. 


2. 1.4-3 

Set gyroscope status to healthy. 


TSP -- Temperature Sensor Processing 

2.1.5 

-1 

Calculate solid state temperature 

2. 1.5-2 

Calculate Thermal Temperature 

2. 1.5-3 

Dctennine which Temperature to use (SS or Thermocouple) 

2.1. 5-3.1 

Calculate the Thermo sensor upper limit 

2.1. 5-3.2 Calculate the Thermo sensor lower limit 

2. 1.5-4 

Dctennine Atmospheric Temperature 

2. 1.5-5 

Set status to healthy. 


TDSP -- Touch Down Sensor Processing 

2.1.6 

-1 

Dctennine status of touch down sensor. 

2. 1.6-2 

Determine whether touch down has been sensed. 

2.2 


GP -- Guidance Processing 

2.2-1 


Rotate variables. 

2.2-2 


Detennine the attitude, velocities, and altitude. 

2.2-2. 1 

Set up the GP ROTATION matrix. 

2 . 2-22 

Calculate new values of attitude, velocity, and altitude. 


TDLRSP NR J105.TC 
TDLRSP NR 007.TC 
TDLRSP NR J108.TC 
TDLRSP NR 009.TC 
TDLRSP NRJ110.TC 
TDLRSP NR Oil, TC 
TDLRSP NR J112.TC 
TDLRSP NR013.TC 
TDLRSP NR 014.TC 
TDLRSP NR 015.TC 
TDLRSP NR 01 6.TC 
TDLRSP NR 0 1 7.TC 
TDLRSP NR O 1 8.TC 
TDLRSP NR 019. TC 
TDLRSP NR 020.TC 
TDLRSP NR 001 .TC, 
TDLRSP NR021.TC 
TDLRSP NR 001.TC 



TDLRSP NR 007-010.TC 
TDLRSP NR 00 1 .TC 
TDLRSP NR 007-010.TC 
TDLRSP NR00LTC 
TDLRSP NR 007-0 10. TC 
TDLRSP NR 001. TC 
TDLRSP NR 00 1 .TC 

GSP NR 001.TC 


GSP NR 001, TC 
GSP NR 001. TC 
GSP NR 001. TC 

TSPNR 001-002.TC 
TSPNR00 1 ,TC 

TSPNR 00 1-002. TC 
TSPNR 00 1-002. TC 
TSPNR 00 1-002. TC 
TSPNR00 1 .TC 

TDSP NR 001-003.TC 
TDSPNR 001-003.TC 

GPNR 00 1-008. TC 

GP NR 001-008.TC 
GP NR 001-008.TC 
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2.2-3 Determine if the engines should be on or off. 


2.2-3. 1 Engines on 


2.2-3.2 Engines off 


Set FRAME ENGINES IGNITED 


2.2-5 Determine velocity error. 


2.2-6 Determine optimal velocity 


2.2-7 Detennine if contour has been crossed. 


2.2-8 Detennine guidance phase. 


2.2-8. 1 GP PHASE = 1 


2.2-8.2 GP PHASE = 2 


2.2-83 GP PHASE = 3 


GP PHASE = 4 


2.2-8. 5 GP PHASE = 5 


2.2-9 Detennine which set of control law parameters to use. 


2.2-9. 1 CL = 1 


22 - 9.2 CL = 2 


2.3 CLP — Control Law Processing 


AECLP -- Axial Engine Control Law Processing 


2.3. 1-1 Generate the appropriate axial engine commands when 
AE CMD=ON. 


2 .3 . 1 - 1 . 1 Detennine engine temperature 


2.3. 1-1. 1.1 AETEMP = COLD 


2.3. 1-1. 1.2 AE_TEMP = WARM 


2.3. 1-1. 1.3 AETEMP = HOT 


2. 3. 1-1. 2 Compute limiting enors for pitch 


2 .3 . 1 - 1 .3 C ompute limiting error for yaw 


2. 3. 1-1. 4 Compute limiting enor for thrust 


2.3. 1-1. 5 Compute pitch, yaw, and thrust errors. 


2.3. 1-1.5. 1 CHUTE RELEASED = 1 


2.3. 1-1. 5. 2 


2.3. 1-1. 5. 3 


2.3. 1-1. 5.4 


CHUTE RELEASRD = 0 


CONTOUR CROSSED = 1 


CONTOUR CROSSED = 0 


2.3. 1-1.6 Compute INTERNAL CMD 


2.3. 1-1.7 Compute axial engine valve settings (AECMD). 


2. 3. 1-1. 7.1 when INTERNAL CMD<0.0 


2.3. 1-1. 7.2 


2.3. 1-1.7. 3 


when 0.0 < INTERNAL CMD > 1.0 


when 1.0 < INTERNAL CMD 


2.3. 1-2 Generate the appropriate axial engine commands when 
AE CMD=OFF. 


2.3. 1-2.1 Set AE CMD = 0 


2.3. 1-3 Set axial engine status to healthy. 


2.3.2 RECLP — Roll Engine Control Law Processing 


2.3 .2-1 Generate the appropriate roll engine command. 


GP NR 003-008.TC 


GPNR 00 1-002. TC 


GP NR 002. TC 


GPNR 00 1-008. TC 


GPNR 00 1-008. TC 


GP NR 001-008.TC 


GP NR 001.TC 


GP NR 001-004.TC 


GP NR 004-008.TC 


GP NR 008.TC 


GP NR 102-106.TC 


GPNR 00 1-008. TC 


GP NR 053. TC 



AECLP NR 00 1 -002 .TC 


AECLP NR 003.TC, AECLP NR 010.TC 


AECLPNR 004-009.TC, 
AECLPNR01 1-012.TC 


AECLPNR001-012.TC 


AECLPNR001-012.TC 


AECLP NR 001-012. TC 


AECLP 

AECLP 


AECLP 

AECLP 


AECLP 

AECLP 


AECLP 

AECLP 


AECLP 

AECLP 


NR004- 

NROll- 


NR001- 
NR 010. 


NR005- 

NR_012. 


NR001- 
NR 010- 


NR00 1 ■ 
NR 055. 


■009. TC, 
■012. TC 


■003 .TC, 
TC 


■009. TC, 
TC 


■004.TC, 

■011.TC 


■0012. TC, 
TC 


AECLP NR 004.TC 


AECLPNR 00 1 -003.TC, 
AECLPNR 006-012.TC 


AECLP NR 055.TC 


AECLP NR 054.TC 


AECLP NR 001-012. TC 


RECLP NR 00 1 -059 .TC, 
RECLP NR 064-068. TC 
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23.2-2 

Set roll engine status to healthy. 

RECLP NR 001-059.TC, 




RECLP NR 064-068. TC 


2.3.3 

CRCP — Chute Release Control Processing 


2. 3.3-1 

Detennine appropriate parachute release command. 


2.3 .3-1.1 

AE TEMP = COLD 

CRCP NR 001-002.TC 

23.3-1.2 

AE TEMP = WARM 

CRCP NR 003-004.TC 

23.3-1.3 

AE TEMP = HOT 

CRCP NR 005-006.TC 

233-1.4 

CHUTE RELEASED = 0 

CRCP NR 00 l.TC, CRCP NR 

003. TC, 



CRCP NR 005.TC 


233-1.5 

CHUTE RELEASED = 1 

CRCP NR 002. TC, CRCP NR 
CRCP NR 006.TC 

004.TC, 


CP — Communications Processing 


2.4-1 

Set communicator status to healthy. 

CP NR 00 1-005. TC 

mm 

Get synchronization pattern. 

CP NR 00 1-005. TC 

mm 

Detennine sequence number. 

CP NR 001-005.TC 


Prepare sample mask. 


2.4-4. 1 

Subframe 1 mask 

CP NR 00 l.TC 


Subframe 2 mask 

CP NR 002. TC 


Subframe 3 mask 

CP NR 003. TC 

mm 

Prepare data section. 


2.4-5. 1 

Use subframe 1 data 

CP NR 00 l.TC 

Em 

Use subframe 2 data 

CP NR 002. TC 

mm 

Use subframe 3 data 

CP NR 003. TC 

2A-2.5 

Calculate checksum. 

CP NR 001-005.TC 


A.ll Test Case Summary 

This section summarizes all the files used in GCS testing into 2 tables and is created for quick 
referencing when carrying out procedures for generating test cases (section A. 12) or executing 
test cases (Test Case Execution Procedures). Files used for requirements-based testing are given 
in Table A. 11-1 and those for structural testing are given in Table A. 11-2. Table A. 11-1 
organizes the files for requirements-based test cases by the four phases as described in the 
Software Verification Plan . Structural test cases in Table A. 11 -2 are divided by the two 
implementations because they are implementation specific. Both tables divide all files into 2 
general groups: 

1 . the files used for generating the test-inputs and expected- values files on the SUN platform 

2. the files used for executing the test cases on the VAX platform. 

Files used for generating test cases are in a separate group because they are generated using 
Mathematica (ref. A.7). For the GCS project, Mathematica is supplied for the SUN platform 
only hence these files are effectively used only on that platform. These files are further divided 
into three groups separated by vertical doted lines. Files specific to a functional unit are listed in 
a row. Files containing actual test data are in the Data Files sub-column; files used in test case 
generation are in the Support Files sub-column; finally, utility files are in their own sub-column. 
The utility files are used throughout the test case generating process and are not specific to any 
functional unit subframe or frame. Although some utility files are used by only a small subset of 
cases, fetching them for other test cases will not hurt if they are not used. As stated in the Test 
Cases Overview, the Data Files are used to generate the Test-Input and Expected- Values files 
using the procedure in section A. 12. It is the TC and EX files that are used in testing the 
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implementations. It should be noted that fdes for generating CP functional unit and trajectory test 
cases are not list in the generating column but given in a special blocks in the executing column. 
This is because trajectory test cases are generated on the VAX running the Venus prototype with 
the GCS Simulator. CP test cases are generated on the VAX because CP is sensitive to the bit 
representation of numerical values. CPNRxx.EX fdes are generated on the VAX from 
CPNRxx.TC fdes. This is more apparent after reviewing the procedures for generating 
trajectory and CP functional unit test cases in section A. 12. 

Files used for executing test cases on the VAX platform are also divided into 3 groups. The 
first group are the Test-Inputs fdes (with “.tc” extension) and Expected- Values fdes (with “.ex” 
or “.seed” extension). These ASCII fdes are the outputs of the test case generating process and 
are transferred from the SUN. Samples of these fdes are given in section A. 14. The second 
group consists of fdes that facilitate test case execution. These fdes are sometime refered to as 
test stubs or test drivers and an example is given in section A. 15. They are, in general, VMS 
FORTRAN fdes and VMS DCL fdes. The third group are again utility fdes used for different 
phases of testing. This section of the table is referenced when carrying out test case execution 
procedures. 
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Table A.l 1-1: File list for requirements-based test suites. 


Test Phase 


Generating 



Executing 



Test Case Input and Expected Values files 

Test Cases with both implementations 


(Using Mathematica on the SUN) 

(Using VAX Fortran Programming Environment) 


Data files 

Support files 

Utility Files 

Output files from 

Test execution 

Utility Files 


(Implementati 

(Implementation 

for 

Mathematica 

support files 

for executing test 


on 

independent) 

generating 

serve as input 

(implementation 

cases 


independent) 


test case 

files for test case 

specific for all 





input and 

execution 

test phases 





expected 


except for 





values files 


trajectory tests) 


Functional 

arsp_nr_xxx.m 

arsp.m 


arsp nr xxx.tc, 

i lnkarsp.com 


Units 

arsp ro xxx.m 

run arsp tc.m 


ex 

i test arsp. for 


NR = Normal 




arsp ro xxx.tc, 



Range T est Case 

asp_nr_xxx.m 

asp.m 


ex 

i lnkasp.com 


RO = 

asp ro xxx.m 

run asp tc.m 



i test asp. for 


Robustness Test 




asp nr xxx.tc, ex 



Case 

gsp_nr_xxx.m 

gsp.m 


asp ro xxx.tc, ex 

i_lnkgsp.com 



gsp_ro_xxx.m 

run_gsp_tc.m 


gsp nr xxx.tc, ex 

i_test_gsp.for 

struct, for inc 


tdlrsp nr xxx. 

tdlrsp. m 


gsp ro xxx.tc, ex 

i lnktdlrsp.com 

commons, for inc 


m 

run tdlrsp tc.m 

input 


i test tdlrsp. for 

compare external. fo 


tdlrsp ro xxx. 


namelistl 

tdlrsp nr xxx.tc, 


r 


m 

tdsp.m 

namelist ex 

ex 

i lnktdsp.com 

compare_guidance . f 



run_tdsp_tc.m 

write nml.m 

tdlrsp ro xxx.tc, 

i test tdsp. for 

or 


tdsp nr xxx.m 


write exnml. 

ex 


compare runpram.f 


tdsp ro xxx.m 

tsp.m 

m 


i lnktsp.com 

or 



run tsp tc.m 


tdspnrxxx.tc, 

i_test_tsp.for 

compare sensor, for 


tsp nr xxx.m 



ex 


read tc.for 


tsp ro xxx.m 

gp.m 


tdsproxxx.tc, 

i_lnkgp.com 

read ex. for 



run_gp.xx 


ex 

i_test_gp.for 

i tc driver.com 


gp_tc.xx 

aeclp. m 


tsp ro xxx.tc, ex 

i lnkaeclp.com 




run aeclp. xx 


tsp nr xxx.tc, ex 

i test aeclp. for 



aeclp tc.xx 

crcp.m 


gp_nr_xxx.te, ex 

i lnkreclp.com 




run_crcp.xx 


gp ro xxx.tc, ex 

i test reclp. for 



crcp tc.xx 

reclp. m 


aeclp nr xxx.tc. 

i lnkcrcp.com 




run reclp. xx 


ex 

i test crcp. for 



reclp tc.xx 



aeclproxxx.tc. 







ex 

i lnkcp.com 
i test cp.for 






reclp nr xxx.tc. 







ex 

(files for 






reclproxxx.tc. 

generating CP 






ex 

expected values) 







common, inc 






crcp nr xxx.tc, 

cp.for 






ex 

cp.com 






crcproxxx.tc, 


name list.inc 





ex 


exname list.inc 





cp_nr_xx.tc, ex 
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Subframe 

sp_00 1 .m arsp.m, asp.m 

sp_001.tc, ex 

i lnksp.com 

cp_ex.for 


■ gsp.m, tsp.m 

itestsp.for 



tdsp.m, tdlrsp.m 

i_sp_driver.com 



mn_gpsf.xx 




gp.m 




gpsf tc.xx ran clp.xx 

gpsfxx.tc, ex 

i lnkgpsf.com 



aeclp.m 

itestgpsf.for 



reclp.m 

i_gpsf_driver.co 



crcp.m 

■ m 



clptc.xx 

clp xx.tc, ex 




- 


i lnkclp.com 



■ 


itestclp.for 



- 


i clp driver, .com 


Frame 

frame xx.m i frame. m i 

frame xx.tc, ex 

i lnkframe.com 



■ run frame tc.m i 


i test frame, for 



■ arsp.m, asp.m, . 


i frame driver, co 



■ gsp.m, tsp.m, i 


m 



! tdsp.m, tdlrsp.m ! 





! gp.m, aeclp.m, ! 





! reclp.m,, crcp.m ! 
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Table A. 1 1- 1 (continued): File list for requirements-based test suites. 


Test Phase 


Generating 

Test Case Input and Expected 
Values files 

(Using Mathematica on the 
SUN) 


Executing 

Test Cases with both implementation, s 
(Using VAX Fortran Programming Environment) 


Output files from 
Mathematica 
serve as input files 
for test case 
execution 


Trajectory 


Simulator Input and expected- 
values files generated on the 


VAX 


traj atm ic xx . tc 
traj _atm_ud_xx . t c 
traj atm xx. seed 


■ Test execution 

■ support files 

■ (implementation 

■ specific for all test 

■ phases except for 

■ trajectory tests) 
i_traj.com 
iruntraj .com 

i build.com 


trajtdicxx.tc 

trajtdudxx.tc 

trajtdxx.seed 


- (files for creating 
trajectory expected 

- values) 

- venusrs.exe 
venus_runges 

_switches.dat 
mnsimi.com 
do_assign.com 
■ venus_traj.com 
mnvenustraj .com 


■ Utility Files 

■ for executing test cases 


traj_sim.exe 

page_align.opt 

gcssimrendezvous.obj 

■ gcs_setup.obj 

gc s_who_am_i . obj 
gcs_list.dat 

■ gcs_sim_switches.dat 
tabular_data.dat 
accuracy.dat 

■ alternate_accuracy.dat 
limits.dat 


Table A. 1 1-1 and A. 1 1-2 are a handy quick references of all the files involved for any specific 
test suite. For example, to regenerate test-input and expected-values files for the GP functional 
unit, the tester may survey Table A. 11-1 and see that gp tc.xx data files are needed; gp.m, and 
run gp.xx support files are needed; and the utility files are needed. 

File names in both Table A. 11-1 and A. 11-2 have been abbreviated to show only the group 
names. Names given in the tables with “xx” and “xxx” in the name denote a group of files where 
the specific file name can be derived by substituting the “x” with two or three digits. The full 
unabbreviated list is given in the Test Case Overview. File names with “i_” in the execution 
support file sub-column are implementation specific where the “i” is the initial of the 
implementation. “P” for Pluto files and “M” for Mercury files. 
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Table A.l 1-2: File list for structural testing of Mercury and Pluto. 


Test Phase 


Generating 


Executing 


(Structural) 

Test Case Input and Expected Values files 

Test Cases with both implementations. 


(Using Mathematica on the SUN) 

(Using VAX Fortran Programming Environment) 


Data files 

Support files ■ Utility Files 

Output files 

Test execution 

Utility Files 



for generating 

from 

support files 

for executing test 



■ test case input 

Mathematica 

(implementatio 

cases 



and expected 

serve as input 

n specific for 




values files 

files for test case 

all test phases 





execution 

except for 
trajectory tests) 


Mercury 

m aeclp st.xx 

m run aeclp st.x - 

m aeclp st.xx.tc, 

m lnkaeclp.com 



X 

ex 

m test aeclp. for 



m _gp_st.xx 

m run_gp st.xx 

m gp st xx.tc, ex 

m lnkgp.com 
m_test_gp.for 



m reclp st.xx 

m run reclp st.x [ 

m reclp st xx.tc. 

m lnkreclp.com 
m test reclp. for 




X 

ex 




m asp st xx. 



m lnkasp.com 



m 


m asp st xx.tc, 

m test asp. for 





ex 

m lnkarsp.com 



m arsp st xx. 



m test arsp. for 





m arsp st xx.tc, 

m lnktdlrsp.com 

struct.for inc 




ex 

m test tdlrsp. for 

commons. for inc 


m tdlrsp st x 




compare external. f 


x.m 

■ input 


m lnktsp.com 

or 



■ namelistl 

m tdlrsp st xx.tc, 

m test tsp. for 

compareguidance.f 



- namelist ex 

ex 


or 


m tsp st 001. 

! write nml.m 



compare runpram.f 


m 

1 write exnml.m 


st driver.com 

or 




m tsp st OOl.tc, 


compare sensor, for 




ex 


read tc.for 
read ex. for 

Pluto 

aeclp_pst_xx. 

run_aeclp_pst.m 

aeclp_pst_xx. tc, 

p lnkaeclp.com 



m 


ex 

p_test_aeclp.for 




run_asp_pst.m 


p lnkasp.com 



asp_pst xx.m 


asp_pst_xx. tc, ex 

p_test_asp.for 




run gp pst.m . gp_pst_st7_code. 


p_lnkgp.com 



gp_pst_xx.m 

! m 

gp_pst_xx. tc, ex 

p_test_gp.for 




write nml st7.m 
write exnml st7. 






run reclp_pst.m m 


p lnkreclp.com 



reclp_pst_xx. 


reclp_pst_xx. tc, 

p_test_reclp.for 



m 


ex 

p_tc_driver.com 
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A.12 Procedure To Generate Test Cases 


All test cases, except trajectory and CP are generated on the SUN platform due to available 
licensing for Mathematica. The files generated on the SUN (the “.tc” and “.ex” files) are then 
transferred to the VAX platform for use in executing the test case for each implementation. The 
file naming convention for each step of the process is given in Tables G-l and will be described 
in the procedures where the files are used. For all functional units other than CP, a model is 
created using Mathematica , before test cases are developed. Mathematica is a programming tool 
that allows complex computations to be easily modeled. 

Generating Functional Unit Requirements-based Test Cases 

All test cases, except trajectory and CP are generated on the SUN platform due to available 
licensing for Mathematica. The files generated on the SUN (files with “.tc” and “.ex” extensions) 
are then transferred to the VAX platform for use in executing the test case for each 
implementation. The file naming convention for each step of the process is given in Tables G-l 
and will be described in the procedures where the files are used. For all functional units other 
than CP, a model is created using Mathematica, before test cases are developed. Mathematica is 
a programming tool that allows complex computations to be easily modeled. Then, based on the 
input list given for a functional unit in the GCS Specification, relevant parameters are identified 
for the test suite for each functional unit. The relevant parameters are all the variables in the 
input list that are a part of the EXTERNAL, SENSOROUTPUT and GUIDANCESTATE data 
stores. Each test case is created by assigning relevant values to the selected parameters in a file to 
be read by Mathematica — the data files. These values are judiciously chosen based on the 
coverage requirement that the test case is to fulfill. As stated in the Software Verification Plan , 
the number of cases in the test suite for each functional unit is minimized by selecting values that 
can satisfy multiple coverage requirements. That is, selecting a particular value for a variable 
may satisfy its valid equivalence class coverage and also satisfy a low-level requirement in the 
traceability matrix. Additionally, Myers (ref. A.8) states that the valid equivalence class of 
several variables can be combined in a single test. These two guidelines serve to significantly 
reduce the number of requirements-based test cases needed to satisfy the coverage requirements 
given in DO-178B. 

The procedures for generating functional unit test-input and expected-values files are given 
below for the functional unit ARSP. The procedure is the same for all functional units except the 
file naming convention changes slightly. This procedure was used to generate the existing test 
cases and only needs to be used if there is a change in the GCS requirements that necessitates a 
change in the test data files or Mathematica models. The procedure presupposes that the user is 
using a UNIX system which has Mathematica. Since the host system for development and 
testing is a VAX system, it is assumed that the user has the capability to transfer files between the 
two hardware platforms. 

1) Create a working directory. All files fetched from CMS should be placed in this 
directory. 

2) Reserve the ARSP data and support files from CMS 

ARSPNRxxx.M 

ARSPROxxx.M 

ARSP.M 

RUN ARSP TC.M 
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Note that files for functional units in the second and third subframe use a slightly 
different naming convention. This procedure uses ARSP as an example, see Table A.l 
for specific file names of other functional units. 

3) Fetch all the utility files: 

The specific file names are given in Table A.l in the last column under the 
GENERATING group. These files give background data for each test case and write the 
actual test-input and expected-values files. 

4) Apply any necessary changes to data and support files: 

ARSP.M models the calculations in ARSP. Should the GCS Specification change 
for ARSP, then this file should be updated. 

ARSPNRxxx.M and ARSPROxxx.M contain the data needed for 
Mathematica to generate the respective test cases. If the test input data need to be 
changed, these are the files to update or new files should be created with the same format 
as those that currently exist. The easiest way to create new data files is to duplicate one 
of the existing files and change the data. When new data files are added to the test suite, 
the file that loads ARSP data files into Mathematica, RUNARSPTC.M, must also be 
updated. This is done by adding an entry into RUN ARSP TC.M specifying the name of 
the new data file. Note that this example gives file names using the naming pattern for 
functional units in the first subframe. Functional units in the second and third subframe 
use the form functional _unit_ TC.xx. If a new test data file is create for this case, a 
corresponding support file must also be created. These support files have the naming 
pattern: RUN Junctional unit. xx. 

5) Run Mathematica: 

Mathematica should be run in the same directory where all the files are placed. As 
currently installed, this is done by the command: 

“math” 

6) Run the data through the model to generate test- input and expected-values: 

For ARSP or any functional unit in the first subframe, use the command: 

«run_arsp_tc.m 

For functional units in the second and third subframe, each test case must be individually 
executed with: 

«run Jimctionalunit.xx 

7) This procedure will create a test-input (“.tc”) and expected-results(“.ex”) file for each 
data file. These files following the same naming convention for all subframes and is as 
follows: 

arspnrxxx.tc or arsproxxx.tc 

arspnrxxx.ex or arsproxxx.ex 

8) Now the files can be replaced into CMS and fetched for test case execution. 


Generating Functional Unit Structure Based Test Cases 

As stated in the GCS Verification Plan, structural testing is performed only at the functional 
unit level. These test cases are derived with the use of McCabe's ACT software. ACT is used to 
generate a decision tree for each functional unit. These trees are in the Verification Results 
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document for each implementation. The decision trees are accompanied by tables indicating the 
decision at each node and the test cases that test the true and false branch of the decision. 

MC/DC is satisfied by performing the following. The verification analyst for each 
implementation compares the test paths to the requirements-based test cases and list, in the tables, 
all the requirements test cases that exercise the test paths in the tables. If there are any decisions 
not exercised by the requirements-based test cases, then test cases are devised to exercise those 
decisions. These cases will be documented in the same table. The process for regenerating the 
test-input and expected-results for structure based cases will be identical to the process for the 
requirements-based cases. The naming conventions for the test cases differ for each 
implementation but the procedure will be the same for both implementations. 

1) Create a working directory. All files fetched from CMS should be placed in this 
directory. 

2) Reserve data and support files: 

Table A.2 gives the file names that need to be reserved for both implementations. Only 
those functional units that currently need structural test cases are given. For any 
functional unit, data and support files as given in Table A.2 should be reserved and 
placed in the same directory. 

3) Fetch all the utility files: 

The specific file names are given in Table A.2 in the last group under the 
GENERATING column. These files give background data for each test case and write 
the actual test-input and expected-values files. 

4) Applying any necessary changes to the data and support files: 

Any changes to the structure of the code in a functional unit will require examining the 
new structure to see if new test cases are necessary. For both implementations, this 
entails regenerating the decision tree graph and modifying the decision tables to add or 
delete decisions. Data files for the test suites (reserved in step 2) must also be updated to 
agree with the new decision table. 

5) Regenerating test- input and expected- values files: 

This step requires launching Mathematica and running the appropriate support files. The 
specific support files for a given functional unit of any implementation is given in Table 
A.2. The procedure for launching Mathematica and running the support file is identical 
to steps 5 and 6 of the functional unit procedure. The difference is the filenames used. 

6) Now the files can be replaced into CMS and fetched for test case execution. 

Generating CP Test Cases 

The functional unit, CP, warrants some special considerations due to the nature of its task. 
Unlike other functional units, CP's function is to create a transmission packet, containing packed 
data and CRC-16 based checksum. Since the result of the checksum is dependent on the bit 
ordering of the data in the packet, it is necessary to generate the expected-results file using the 
same VMS platform that is to run the implementation. This is the only practical way to ensure 
that the checksum generated for each expected-result file is valid. Additionally, since the VMS 
platform provides an algorithm for calculating the checksum based on the CRC-16, a comparative 
algorithm would not have to be devised. It is assumed, for the purposes of the GCS project, that 
the CRC-16 checksum generator supplied by the VMS operating system is flight qualified. So to 
generate the expected-results files for CP test cases, a VAX FORTRAN model is written to build 
the packet and execute the VMS CRC algorithm. 
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CP expected-results are generated on the VAX that also runs the implementations. The 
following procedure is used to generate the expected-results files for CP: 

1) Create a working directory on the VAX. All files fetched from CMS should be placed in 
this directory. 

2) Reserve data files & fetching support and utility files: 

Data files for CP are the same as the CP test-input files given in Table A.l. 
CPNRxxx.TC 

Support files are also given in Table A.l under the VAX support files. This is the group 
at the bottom specially noted. 

COMMON. INC 

CP.FOR 

CP.COM 

Utility files are listed in Table A.2 and also given below: 

NAME_LIST.INC 
EXNAMELI ST. INC 

3) Apply any necessary changes to files: 

Any changes to specific data items should be applied to the CP NR xxx.TC 
Any changes to the functional specification for CP should be applied to CP.FOR 

If new data files are added to the test suite, CP.COM should be changed to add the 
command for generating expected-results files for the new test case. 

4) Regenerating expected-results files: 

“@CP” 

5) Now the files can be replaced into CMS and fetched for test case execution. 


Generating Integration Level Test Cases 

As stated above, integration testing takes place in three phases: subframe, frame, and 
trajectory testing. In both the subframe and frame tests the expected values will be computed 
using the same Mathematica models used in functional unit testing. Instead of operating 
individually, these units are linked together to produce models of the subframe or frame. The 
linked models will be used to generate the appropriate expected values for the subframes and 
frames in a similar manner as for the functional units. The same comparison and pass/fail criteria 
used in the functional unit testing will be used in the subframe and frame testing. As mentioned 
in the Software Verification Plan, only requirements-based software integration testing will be 
performed for GCS implementations. Hence integration test cases will be requirements-based 
only. And, because the GCS Specification requires each implementation to use global data 
stores, the DO-178B requirement to test for parameter passing errors is eliminated. Additionally, 
since the software is not required to perform any kind of data initializations, the DO-178B 
requirement to test for incorrect initializations is also eliminated. This greatly reduces the 
number of test cases necessary during subframe and frame integration testing. The sections 
below describe development of subframe, frame, and trajectory test cases. 
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Generating Subframe Test Cases 

The overall purpose of integration testing at the subframe level is to ensure that functional 
units within each subframe will inter-operate and that linking these units does not introduce 
errors. Additional objectives are given in the test plan found in the Software Verification Plan. 
For subframe integration tests, test cases are created to test subframe requirements as listed in the 
Traceability Matrix. Additionally, cases will be selected from the functional unit tests that 
exercise critical state transitions within a subframe. These cases are documented in the 
Traceability Matrix in section A.6 and also listed in Table A. 1. The procedure for generating 
subframe test-inputs and expected-results are as follows: 

1) Create a working directory on the UNIX environment. All files fetched from CMS 
should be placed in this directory. 

2) Depending on the subframe to regenerate, reserve the data and output files as given 
below. Also fetch support and utility files as indicated below (These files are also given 
in Table A.l) : 



Data files 

Support 

Files 

Utility Files 

Output Files 

Subframe 1 

SP001.M 

ARSP.M 

ASP.M 

GSP.M 

TSP.M 

TDSP.M 

TDLRSP.M 

INPUT 

WRITE NML.M 
WRITE EXNML. 
M 

SP 00 l.TC 
SP 00 l.EX 

Subframe 2 

GPSFTC.xx 

RUN GPSF.xx 
GP.M 

INPUT 
NAMELIST 1 
NAMELISTEX 

GPSF xxx. TC 
GPSFxxx.EX 

Subframe 3 

CLP TC.xx 

RUN CLP. xx 
AECLP.M 
RECLP.M 
CRCP.M 

INPUT 
NAMELIST 1 
NAMELIST EX 

CLP xxx.TC 
CLP xxx.EX 


3) Apply any necessary changes to files: 

As in the previous procedures, If test data needs to be modified, the data files should be 
changed. If any of the functional unit models are modified, then this procedure must be 
carried out to regenerate the subframe test cases. 

4) Regenerating test- input and expected- values files: 

Run Mathematica from the directory where the files are located. Then 
for Subframe 1 : 

“«sp_001.m” 
for Subframe 2: 

“«run_gpsf.xx” ( Where the command has to be repeated for each test case 
number xx. ) 

for Subframe 3 : 

“«run_clp.xx” ( Where the command has to be repeated for each test case 
number xx. ) 

5) Now the files can be replaced into CMS and fetched for testing with the GCS 
implementations. 
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Generating Frame Test Cases 

The integration testing at the frame level is to ensure that the three subframes are independent 
and that linking these subframes does not introduce errors. Enough cases will be selected so that 
all state transitions will be tested as well as some random single frames. Multiple frame tests will 
be covered in the Trajectory Testing. 

The frame test case development process will closely follow the subframe process. That is, 
the Mathematica models of all functional units are linked together to create the frame model 
FRAME.M. This includes all functional units except for CP and SimRendezvous. Like 
subframe testing, test cases will be input into the model to generate the test case input files and 
expected results files. The procedure for generating frame test-input and expected-values is 
identical to that for the subframe except for the files involved: 

1) Create a working directory on the UNIX environment. All files fetched from CMS 
should be placed in this directory. 

2) Reserve the output files and fetch the data, support, and utility files listed below: 


Data files 

Support Files 

Utility Files 

Output Files 

FRAMEXXX.M 

FRAME.M 

INPUT 

FRAME XXX. TC 


RUN FRAME TC.M 
ARSP.M 
ASP.M 
GSP.M 
TSP.M 
TDSP.M 
TDLRSP.M 
GP.M 
AECLP.M 
RECLP.M 
CRCP.M 

WRITE NML.M 
WRITE EXNML.M 

FRAME XXX.EX 


3) Apply any necessary changes to files: 

As in the previous procedures, If test data need to be modified, the data files 
(FRAMExxx.M) should be changed. If any of the functional unit models are modified, 
then this procedure must be carried out to regenerate the frame test cases. 

4) Regenerating test- input and expected-values files: 

Run Mathematica from the directory where the files are located. Then within 
Mathematica enter the command: 

“«run_frame_tc.m” ( This command will regenerate all test frame test 

cases.) 

5) Now the files can be replaced into CMS and fetched for testing with the GCS 
implementations. 


Generating Trajectory Test Cases 

As indicated in Table A.21, there are two input files for each trajectory test case. All files with 
"IC" in the name correspond to the INITIAL_CONSTANTS.DAT file required by the simulator. 
All files with the "UD" in the name correspond to the USAGE_DISTRIBUTIONS.DAT file used 
by the simulator. The "ATM" and "TD" stand for the names of the respective groups. The files 
are renamed by the test drivers to the appropriate names as required by the GCS Simulator prior 
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to simulator execution. These data files are created on the VAX system that will run the 
simulator. As Table A. 11-1 and Table A.21 indicates, there is also a “.SEED” file for every 
trajectory test case. This is the expected-values file for each trajectory test. The “.SEED” files 
are generated by running the simulator with the VENUS prototype of GCS. Elence the procedure 
for generating trajectory expected-values files is similar to those for executing trajectory test 
cases: 

1) A directory structure similar to the one for trajectory test case execution must first be 
created on the VAX. 

2) Fetch the following from CMS and placed into the [TRAJ] directory 

a) Trajectory testing utility files as listed in Table A. 1 except object files and 
PAGEALIGN.OPT : 

ACCURACY.DAT 

ALTERNATE_ACCURACY.DAT 

GCS_LIST.DAT 

GCS_SIM_SWITCHES.DAT 

LIMITS.DAT 

TABULAR_DATA.DAT 

TRAJ_SIM.EXE 

b) The following files for the VENUS prototype: 

VENUSRS.EXE 

VENUS_RUNGES_SWITCHES.DAT 

RUNSIMI.COM 

DO_ASSIGN.COM 

VENUS_TRAJ.COM 

RUN_VENUS_TRAJ.COM 

3) Fetch the following from CMS and place in the [ATM] directory: 

TRAJATMICxxx.TC 
TRAJATMUDxxx.TC 
TRAJ_ATM_ xxx. SEED 

4) Fetch the following from CMS and place in the [TD] directory: 

TRAJTDICxxx.TC 
TRAJTDUDxxx.TC 
TRAJ_TD_ xxx. SEED 

5) The “.SEED” files can then be generated by executing the following command from the 
[TRAJ] directory at the operating system prompt: 

“@run_venus_traj ” 

6) Now the files can be replaced into CMS and fetched for testing with the GCS 
implementations. Note that the “.SEED” files are spread between the [ATM] and [TD] 
directories. 

A.13 Mathematica Models 

The following are the Mathematica models used to generate the expected results for each test 
case. There is a model for each functional unit except for CP. CP test cases were created using 
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special procedures in place of the Mathematica model expected. These procedure are described 
above in the section Special Procedures for Developing CP Test Cases. Not included in this 
section are models for subframe and frame testing. Those models simply call the respective 
functional unit models appropriate subframe and all the models for the frame. 

All attempts have been made to keep the copies in this document current. If there are any 
discrepancies, the version of the model in CMS should supersede the version of the model in this 
document. 
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AECLP 




(* Filename : aeclp.tc.code *) 

(■* 

(* Description: *) 

(■* 

(* This file contains the Mathematica code to calculate the expected values *) 

(* for AECLP. *) 

(* The following assumptions are made: *) 

(* 1) the data related to the 4 GCS data stores are pre-loaded *) 

(* 2) the specific data for a test case is also loaded *) 


(* rotate the variables *) 

GPALTO = GPALT[[1]] 

GPALT1 = GPALT[[2]] 

GPALT2 = GPALT[[3]] 

GPALT3 = GPALT[[4]] 

GPALT4 = GPALT[[5]] 

(* set up the GROT and GPROT arrays *) 


qO = QV 
rO = RV 

Array [GPROTO, {3,3}] 

GROTO = N[{pO, qO, rO}, 30] 

GPROTO =N[{{0, rO, -qO}, {-rO, 0, p0}, {qO, -pO, 0}}, 30] 
GROT1 =N[{pl, ql, rl } , 30] 

GPROT 1 = N[{{0, rl, -ql}, {-rl, 0, pi}, {ql, -pi, 0}}, 30] 
GROT2 = N[{p2, q2, r2}, 30] 

GPROT2 = N[{{0, r2, -q2}, {-r2, 0, p2}, {q2, -p2, 0}}, 30] 
GROT3 = N[{p3, q3, r3}, 30] 

GPROT3 =N[{{0, r3, -q3}, {-r3, 0, p3}, [q3, -p3,0}},30] 
GROT4 = N[{p4, q4, r4 } , 30] 

GPROT4 = N[{{0, r4, -q4}, {-r4, 0, p4}, {q4, -p4, 0}}, 30] 

(* set up the matrix needed for INTERNALCMD calcualtion *) 
MM1 = {{GP1, 0., 1.}, {GP2, -GPY, 1.}, {GP2, GPY, 1}} 


(* set the local variables in the test case equal to the namelist variables *) 

CHUTREL = CHUTR 
CONTCROSSED = CONTC 
ENGONALT = EOALT 
FRAMECOUNTER = FRAMEC 
FRMENGIGN = FRMEI 
GPVEL0[[1,1]] = XDOT 
GPVEL0[[2,1]] = YDOT 
GPVEL0[[3,l]]=ZDOT 
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AACCO[[ 1,1]] = XDDOT 
GROTO[[2]] = QV 
GROTO[[3]] = RV 

Print [ALPHA] 


(* Compute Limiting error for Pitch and Yaw *) 


If[ AES WITCH != 0, 

FTIME = N[(FRAMEC - FRMEI)*DELT, 20]; 

If[GPALT0 <= EOALT && AETEMP == 0 && FTIME < FULLUPT, AETEMP =1]; 
If[GPALT0 <= EOALT && AETEMP == 1 && FTIME >= FULLUPT, AETEMP = 2]; 

PEI = N[PEI + DELT * ZDOT/Abs[XDOT], 20]; 

YEI = N[YEI + DELT * YDOT/Abs[XDOT], 20]; 

PEL = N[GQ[[CL]]*QV + GW[[CL]]*ZDOT/Abs[XDOT] + GWI[[CL]]*PEI]; 

If[PEL < PEMIN[[CL]], PEL = PEMIN[[CL]]]; 

If[PEL > PEMAX[[CL]], PEL = PEMAX[[CL]]]; 

YEL = N[-GR[[CL]]*RV + GV[[CL]]*YDOT/Abs[XDOT] + GVI[[CL]]*YEI]; 

If[YEL < YEMIN[[CL]], YEL = YEMIN[[CL]]]; 

If[YEL > YEMAX[[CL]], YEL = YEMAX[[CL]]]; 


] 


(* Compute Liniting Error for Thurst *) 


If[CONTC != 0 && AESWITCH != 0, 

TEI = N[TEI + DELT * VELERR, 20]; 

X = N[-GAX * (XDDOT + GRAVITY*GPATT0[[ 1,3]]) + GVE*VELERR + GVEI[[CL]]*TEI, 30]; 

XI = N[(X*GA)/OMEGA, 30]; 

EOMEG = N[E A -(OMEGA*DELT), 30]; 

TEL = N[X1 + (TEL - Xl)*EOMEG, 30]; 

If[TEL < TEMIN[[CL]], TEL = TEMIN[[CL]]]; 

If[TEL > TEMAX[[CL]], TEL = TEMAX[[CL]]] 

] 


(* Compute Pitch, Yaw and Thrust errors *) 


IA= {0., 0., 0.} 

If[ AESWITCH !=0, 

If[CHUTR = 1 && CONTC == 1, PE = N[PEL,30]]; 
If[CHUTR = 1 && CONTC == 1, YE = N[YEL,30]]; 
If[CHUTR = 1 && CONTC == 1, TE = N[TEL,30]]; 

If[CHUTR = 1 && CONTC == 0, PE = N[PEL,30]]; 
If[CHUTR = 1 && CONTC == 0, YE = N[YEL,30]]; 
If[CHUTR == 1 && CONTC == 0, TE = N[TEDROP,30]]; 

PI =N[GQ[[CL]]*QV, 20]; 

Y1 = N[-GR[[CL]]*RV, 20]; 

If[CHUTR == 0, PE = PI]; 
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If[CHUTR = 0, YE = Yl]; 

If[CHUTR == 0, TE = TEINIT]; 

MM2 = {PE, YE, TE}; 

(* Print [StringForm["PE = PE]]; *) 

(* Print [ StringF orm[ "YE = YE]]; *) 

(* Print [StringForm["TE = "", TE]]; *) 

(* compute INTERN AL COMMAND *) 

INTERCMD = N[MM1 . MM2, 20]; 

(* Print [StringForm["MMl MM1]]; *) 

(* Print [StringForm["MM2 - MM2]]; *) 

(* Print [ StringF orm[ "INTERCMD = "", INTERCMD]]; *) 


(* compute AECMD *) 


IA = 127 INTERCMD; 

If[INTERCMD[[l]] < 0., IA[[1]] = 0.]; 

If[INTERCMD[[l]] > 1., IA[[1]] = 127.]; 

If[INTERCMD[[2]] < 0., IA[[2]] = 0.]; 

If[INTERCMD[[2]] > 1., IA[[2]] = 127.]; 

If[INTERCMD[[3]] < 0., IA[[3]] = 0.]; 

If[INTERCMD[[3]] > 1., IA[[3]] = 127.] 

] 

AECMD = Round[IA] 

(* ALPHA = "\nAECLP Test Outputs:\n" *) 

(* Print [ALPHA] *) 

(* Print [ StringF orm[ " AETEMP = " ", AETEMP]] *) 

(* Print [ StringF orm[ " AE_ST ATU S = ”", AESTATUS]] *) 

(* Print [ StringF orm[ "PE INTEGRAL = ' ' PEI]] *) 

(* Print [ StringF orm[ "TE INTEGRAL = TEI]] *) 

(* Print [ StringF orm[ "TE LIMIT = " ", TEL]] *) 

(* Print [StringForm["YE_INTEGRAL = ' ' YEI]] *) 

(* Print [ StringF orm[ "INTERN AL CMD = ”", INTERCMD]] *) 
(* Print [ StringF orm[ " AE CMD = Round[IA]]] *) 
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ARSP 




(* Filename : arsp.m *) 

(* Create Date : 6-27-94 *) 

(* Description: *) 

(* This file contains the Mathematica code to calculate expected values *) 

(* for ARSP functional unit. The following assumotions are made: *) 

(* 1) data related to the 4 GCS data stores are pre-loaded. *) 

(* 2) the specific data for a test case is also loaded *) 


(* Local variables added for readability *) 
healthy = 0 (* used for ARSTATUS *) 

failed = 1 (* used for AR STATUS *) 

(**** Rotate history variables ****) 

(* ARALTITUDE *) 

ARALT4 = ARALT3 
ARALT3 = ARALT2 
ARALT2 = ARALT1 
ARALT1 = ARALTO 

(* AR STATUS *) 

ARSTATUS4 = ARSTATUS3 
ARSTATUS3 = ARSTATUS2 
ARSTATUS2 = ARSTATUS 1 
ARSTATUS 1 = ARSTATUSO 

(* KALT *) 

KALT4 = KALT3 
KALT 3 = KALT2 
KALT2 = KALT1 
KALT 1 = KALTO 

(**** Calculate AR ALTITUDE ****) 

If [ ARCOUNTER > 0 

, ARALTO = (ARCOUNTER 3 10 A 8) / (ARFREQ 2) (* echo received *) 

, IF [ (ARSTATUS4 == healthy) (* echo not received *) 

&& (ARSTATUS3 == healthy) 

&& (ARSTATUS2 == healthy) 

&& (ARSTATUS 1 == healthy) 

, ARALTO = 4 ARALT1 - 6 ARALT2 (* extimate w/ 3rd order poly *) 
+ 4 ARALT3 - ARALT4 

, ARALTO = ARALT1 (* set to previous value *) 

] 

] 

(**** Set AR STATUS and K ALT ****) 

If [ ARCOUNTER > 0 
, ARSTATUSO = healthy; 

KALTO = 1 
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, ARSTATUSO = failed; 
IF [ (ARSTATUS4 == 
&& (ARSTATUS3 = 
&& (ARSTATUS2 = 
&& (ARSTATUS1 = 
, KALT = 1 
, KALT = 0 ] 


healthy) 

= healthy) 
= healthy) 
= healthy) 



ASP 


Filename : asp.m 

Create Date : 6-27-94 
Description: 

This file contains the Mathematica code to calculate expected values 
for ASP functional unit. The following assumptions are made: 

1) data related to the 4 GCS data stores are pre-loaded. 

2) the specific data for a test case is also loaded 
Flistory: 

VO: created (CCQ) 

VI: update to reflect GCS Spec Mod2.3-7 (CCQ) 
new IF block for determining ASTATUS 

debug =1 (* set to 1 for status and debug messages *) 

(* Local variables added for readability *) 
healthy = 0 (* used for A STATUS *) 

failed = 1 (* used for A STATUS *) 

If [ debug==l, Print["Rotate history..."] ] 

(**** Rotate history variables ****) 

(* AACCELERATION *) 

AACC4 = AACC3 
AACC3 = AACC2 
AACC2 = AACC 1 
AACC1 = AACCO 

(* A_STATUS *) 

ASTATUS4 = ASTATUS3 
ASTATUS3 = ASTATUS2 
ASTATUS2 = ASTATUS 1 
ASTATUS 1 = ASTATUSO 

If [ debug==l, Print[" Adjust G GAIN..."] ] 

(**** Adjust A_GAIN() for temperature ****) 
again = { N[ AGAIN0[[1]] + G1 ATMTEMP + G2 ATMTEMP A 2, 30] 
,N[ AGAIN0[[2]] + G1 ATMTEMP + G2 ATMTEMP A 2, 30] 

,N[ AGAIN0[[3]] + G1 ATMTEMP + G2 ATMTEMP A 2, 30] 

} 


If [ debug==l, Print["Remove Bias..."] ] 

(**** REMOVE CHARACTERISTIC BIAS ****) 
aaccelm = { N[ ABIAS[[1]] + again[[l]] ACOUNTER[[l]], 30] 
,N[ ABIAS[[2]] + again[[2]] ACOUNTER[[2]], 30] 
,N[ ABIAS[[3]] + again[[3]] ACOUNTER[[3]], 30] 

} 


If [ debug==l, Print["Correct misallignment..."] ] 

(**** Correct for Misalignment ****) 

(** NOTE: matrix multiply **) 
aacc = N[ ALPMAT . aaccelm, 30] 

(** NOTE: this is a reassignment to correct for the way AACC is declared in the INPUT file. **) 
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AACCO[[ 1,1]] = aacc[[l]] 
AACC0[[2,l]] = aacc[[2]] 
AACC0[[3,1]] = aacc[[3]] 


If [debug==l, Print["determine acceleration..."] ] 

(**** Determine accelerations and accelerometer status ****) 

(* old code from VO *) 

(* comments had to be removed from old code, 

Mathematica will not allow embeded comments. 


For[ axis=l, axis<=3, axis++. 

If [ (ASTATUS3 [[axis]] == healthy) 

&& (ASTATUS2[[axis]] == healthy) 

&& (ASTATUSl[[axis]] == healthy) 

mean = N[ ( AACCl[[axis,l]] 

+AACC2[[axis,l]] 

+AACC3[[axis,l]])/3, 30]; 
std = N[ Sqrt[ (( (AACCl[[axis,l]] - mean) A 2 
+(AACC2[[axis, 1]] - mean) A 2 
+(AACC3[[axis, 1]] - mean) A 2 
) / 3) 

], 30]; 

If [debug==l, Print["ax[[",axis,",l]]:: mean=",mean," & std=",std]]; 
If [debug==l, Print["ax[[",axis,",l]]=",aacc[[axis]] ]]; 

If [debug==l, Print["Perform std-compare. .."]]; 

If [ Abs[ mean - AACC0[[axis,l]] ] > (ASCALE std) 

, AACC0[[axis,l]] = N[mean,30]; 

ASTATUS0[[axis]] = failed; 

If [debug==l, Print["axis[[",axis,",l]] = mean value"]] 

, ASTATUS0[[axis]] = healthy; 

If [debug==l, Print["axis[[",axis,",l]] = sensor value"]] 

I 

If [debug==l, Print["In ELSE branch..."]]; 

ASTATUS0[[axis]] = healthy 

] 

] 

*) 

(* new code for VI *) 

If [debug==l, Print["Start new code"]] 

If [debug==l, Print[ASTATUSO] ] 

If [debug==l, Print[ASTATUSl] ] 

If [debug==l, Print[ASTATUS2] ] 

If [debug==l, Print[ASTATUS3] ] 

If [debug==l, Print[ASTATUS4] ] 

For[ axis=l, axis<=3, axis++, 

ASTATUS0[[axis]] = healthy; 

If [debug==l, Print["ASTATUSO[[",axis,"]]",ASTATUSO[[axis]] ]]; 

If [debug==l, Print["a_status =" 

,ASTATUS3[[axis]] 

,ASTATUS2[[axis]] 

,ASTATUS 1 [[axis]] 
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]]; 

If [ (AST ATUS3 [[axis]] == healthy) 

&& (AST ATU S2 [ [axis]] == healthy) 

&& (AST ATU S 1 [ [axis]] == healthy) 

,(* check extreme values and set A STATUS, & AACCELERATION *) 
If [ (AACCl[[axis,l]] != AACC2[[axis,l]]) 

||(AACCl[[axis,l]] != AACC3[[axis,l]]) 

, mean = N[ ( AACC1 [[axis, 1]] 

+A ACC2 [ [axis, 1 ] ] 

+AACC3[[axis,l]]) / 3, 30]; (* 30 dig. accuracy *) 
std = N[ Sqrt[ (( (AACCl[[axis,l]] - mean) A 2 
+(AACC2[[axis,l]] - mean) A 2 
+(AACC3[[axis,l]] - mean) A 2 
) / 3) 

], 30]; (* 30 digits of accuracy *) 

If [debug=l, 

Print["ax[[",axis,",l]]:: mean=",mean," & std=",std]; 
Print["ax[[",axis,",l]]=",aacc[[axis]] ]; 

Print["Perform std-compare..."] 

]; 

If [ Abs[ mean - AACC0[[axis,l]] ] > (ASCALE std) 

, AACC0[[axis,l]] = N[mean,30]; (* eliminate outlier numbers *) 
ASTATUS0[[axis]] = failed; 

If [debug==l, Printf" axis[[",axis,",l]] = mean value"]] 

I 

] (* close second If statement *) 

] (* close first If statement *) 

] (* close for loop *) 

If [debug==l, Print[" After:"] ] 

If [debug==l, Print[ASTATUSO] ] 

If [debug==l. Print [AST ATU SI] ] 

If [debug==l. Print [AST ATU S2 ] ] 

If [debug==l, Print[ASTATUS3 ] ] 

If [debug==l, Print[ASTATUS4] ] 

lf[debug==l, Print["Finninhed ASP !!"] ] 
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GP 




(* Filename : gp.m *) 

(■* 

(* Description: *) 

(■* 

(* This file contains the Mathematica code to calculate the expected values *) 

(* for GP. *) 

(* The following assumptions are made: *) 

(* 1) the data related to the 4 GCS data stores are pre-loaded *) 

(* 2) the specific data for a test case is also loaded *) 


(* rotate the variables *) 


GPATT4 = GPATT3 
GPATT3 = GPATT2 
GPATT2 = GPATT1 
GPATT1 = GPATTO 

GPVEL4 = GPVEL3 
GPVEL3 = GPVEL2 
GPVEL2 = GPVEL1 
GPVEL1 = GPVELO 

GPALT4 = GPALT3 
GPALT3 = GPALT2 
GPALT2 = GPALT1 
GPALT1 = GPALTO 

(* Runga-Kutta *) 

h = 2.*DELTAT 

(* first estimates *) 

kl = N[h (GPROT2 . GPATT2 ), 30] 

Array [GPATI3, {3,1}] 

GPATI3 =N[{{GPATT2[[1,3]]}, {GPATT2[[2,3]]}, {GPATT2[[3,3]]}}, 30] 

Array [gprv, {3,1}] 

Array [tdlgpv, {3,1}] 

Array [11, {3,1}] 

Array [GPROT2, {3,3}] 

Array [GPVEL2, {3,1}] 

gprv = N[GPROT2.GPVEL2, 30] 
tdlgpv = N[TDLRVEL2 - GPVEL2, 30] 

Ktdlgpv = N[KMATRIX2 . tdlgpv, 30] 
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Print [ALPHA] 

11 = N[h (gprv + GRAVITY GPATI3 + AACC2 + Ktdlgpv), 30] 

Array [GPATI1, {1,3}] 

GPATI1 = N[{GPATT2[[1,3]], GPATT2[[2,3]], GPATT2[[3,3]]}, 30] 
m =N[h (-GPATI1.GPVEL2 + KALT[[3]]*(ARALT2-GPALT2)), 30] 
ml =N[m[[l]], 30] 


(* second estimates *) 


K12 = N[.5 kl, 30] 

L12 = N[.5 11, 30] 

M12 = N[.5*ml, 30] 

GPATI = N[GPATT2 + K12, 30] 
k2 = N[h (GPROT1. (GPATI)), 30] 


Array [12, {3,1}] 


gprv = N[GPR0T1.(GPVEL2+L12), 30] 
tdlgpv = N[TDLRVEL1 - (GPVEL2+L12), 30] 
Ktdlgpv = N[KMATRIX1 . tdlgpv, 30] 


GPATI3 = N[{{GPATI[[1,3]]}, {GPATI[[2,3]]}, {GPATI[[3,3]]}}, 30] 

12 = N[h (gprv + GRAVITY GPATI3 + AACC1 + Ktdlgpv), 30] 

GPATI 1 = N[{GPATI[[1,3]], GPATI[[2,3]], GPATI[[3,3]]}, 30] 
m =N[h ( -GPATI 1 . (GP VEL2+L 12) + KALT[[2]]*(ARALT1 - (GPALT2+M12))), 30] 
m2 = N[m[[l]], 30] 


(* third estimates *) 


K22=N[.5k2, 30] 

L22 = N[.5 12, 30] 

M22 = N[.5*m2, 30] 

GPATI = N[GPATT2 + K22, 30] 
k3 = N[h (GPROT1. (GPATI)), 30] 


Array [13, {3,1}] 


gprv = N[GPROT 1 .(GPVEL2+L22), 30] 
tdlgpv = N[TDLRVEL1 - (GPVEL2+L22), 30] 
Ktdlgpv = N[KMATRIX1 . tdlgpv, 30] 


GPATI3 = N[{{GPATI[[1,3]]}, {GPATI[[2,3]]}, {GPATI[[3,3]]}}, 30] 

13 =N[h (gprv + GRAVITY GPATI3 + AACC1 + Ktdlgpv), 30] 

GPATI 1 = N[{GPATI[[1,3]], GPATI[[2,3]], GPATI[[3,3]]}, 30] 
m =N[h ( -GPATI 1 . (GP VEL2+L22) + KALT[[2]]*(ARALT1 - (GPALT2+M22))), 30] 
m3 = N[m[[l]], 30] 


(* forth estimates *) 


GPATI = N[GPATT2 + k3, 30] 
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k4 = N[h (GPROTO.(GPATI)), 30] 

Array [14, {3,1}] 

gprv = N[GPROTO.(GPVEL2+13), 30] 
tdlgpv = NfTDLRVELO - (GPVEL2+13), 30] 
Ktdlgpv = NfKMATRIXO . tdlgpv, 30] 


GPATI3 = N[{{GPATI[[1,3]]}, {GPATI[[2,3]]}, {GPATI[[3,3]]}}, 30] 

14 = N[h (gprv + GRAVITY GPATI3 + AACCO + Ktdlgpv), 30] 

GPATI1 = N[{GPATI[[1,3]], GPATI[[2,3]], GPATI[[3,3]]}, 30] 
m =N[h ( -GP ATI 1 . (GP VEL2+13 ) + KALT[[1]]*(ARALT0 - (GPALT2+m3))), 30] 
m4 = N[m[[l]], 30] 

(* calculate new values of GP ATTITUDE, GP_VELOCITY and GP ALTITUDE *) 

GPATTO = N[GPATT2 + 1./6. (kl + 2. (k2 + k3) + k4), 30] 

GPVELO = N[GPVEL2 + 1./6. (11+2. (12 + 13) + 14), 30] 

GPALTO = N[GPALT2 + l./6.*(ml + 2.*(m2 + m3) + m4), 30] 


(■* *■) 

(* equation from table 5.9 *) 

*■) 

(** Old code before VI Spec. Mod. 2.3-7 requires this change **********) 
(* X = N[2.*GRAVITY*GPALT0, 30] *) 

(* DUM = N[Sqrt[X] + GPVEL0[[1,1]], 30] *) 

(* XI = N[DUM, 30] *) 



(* New code for VI - added Max function to avoid negative square root *) 

X = N[2. * GRAVITY * Max[GPALT0,0], 30] 

DUM = N[Sqrt[X] + GPVEL0[[1,1]], 30] 

XI = N[DUM, 30] 


(* This section implements table 5.9 *) 

(* AES WITCH = 0, OFF *) 

(* AE SWITCH = 1, ON *) 

(* TDSENSED = 0, TD NOT SENSED *) 
(* TD SENSED = 1, TD SENSED *) 


(* tengon is a local variable, it is only used to indicate that the engines *) 

(* are off and will be turned on after GP is exited. This is a problem with *) 

(* AESWITCH being turned on for the first time ... but the engines are still*) 
(* off as far as the GP PHASE condition meter is concerned *) 


tengon = 0 


Iff AES WITCH == 1 && GPALTO <= DROPHEIGHT && XI <= MAXNORMVEL && 
TDSENSED ==0, 

AESWITCH = 0; 

RESWITCH = 0 

] 

Iff AESWITCH == 1 && TDSENSED == 1, 
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AESWITCH = 0; 
RESWITCH = 0 


If[ AESWITCH == 0 && GPALTO <= ENGONALT && TD SENSED ==0 && RESWITCH 
FRMENGIGN = FRAMECOUNTER; 

AESWITCH = 1; 
tengon = 1 


(* DETERMINE OPTVEL : Find the present altitude in CONTALT and locate the *) 
(* corresponding velocity in CONTVEL. Interpolate if necessary *) 

(* first put CONTALT and CONTVEL into the correct units *) 

KCONTALT = N[1000. CONTALT] 

KCONTVEL = N[1000. CONTVEL] 

(* NOTE : fix this in case there are more than 18 values *) 


ALTMIN = KCONTALT[[l]] 
ALTMAX = KCONTALT[[2]] 
VELMIN = KCONTVEL[[l]] 
VELMAX = KCONTVEL[[2]] 


Do[ 

If[GPALT0 > KCONTALT[[i]], 
ALTMIN = KCONTALT[[i]]; 
VELMIN = KCONTVEL[[i]]; 
ALTMAX = KCONTALT[[i+l]]; 
VELMAX = KCONTVEL[[i+ 1 ]] ; 
], {1 17}] 


(* compute the optimal_velocity *) 


OPTVEL = GPVEL0[[1,1]] 

If] ALTMIN != ALTMAX, 

SLOPE = N[(VELMAX - VELMIN)/(ALTMAX - ALTMIN), 30]; 
OPTVEL = N[SLOPE*(GPALTO - ALTMIN) + VELMIN, 30] 

] 


(* Print [ StringF orm[ "OPTVEL = OPTVEL]] *) 

(* compute VELOCITY_ ERROR *) 

DUM = N[GPVEL0[[1,1]] - OPTVEL, 30] 
VELERR = N[DUM, 30] 


(* CONTCROSSED = 0, Contour not crossed *) 

(* CONT CROSSED = 1, Contour crossed *) 

IfIGPALTO <= ENGONALT && CONTCROSSED = 0 && VELERR >= 0., 
CONTCROSSED = 1] 


(* Determine GP_PHASE *) 
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(* AES WITCH = 0, Engins OFF *) 

(* AES WITCH = 1 , Engins ON * ) 

(* TDSENSED = 0, TD NOT SENSED *) 
(* TD SENSED = 1, TD SENSED *) 

(* CONTCROSSED = 0, Contour not crossed *) 
(* CONT CROSSED = 1, Contour crossed *) 
(* CHUTEREL = 0, Chute attached *) 

(* CHUTE REL = 1, Chute released *) 


(* PHASE 2 *) 

If[GPPHASE == 1 && GPALTO <= ENGONALT 
,GPPHASE = 2] 

(*If[GPPHASE == 1, idum = 1] *) 

(*If[ GPALTO <= ENGONALT && idum == 1, idum = 2] *) 

(*Print [StringForm["idum = ' ' ",idum]] *) 

(*If[idum == 2, GPPHASE = 2] *) 

(* PHASE 3 *) 

If[ GPPHASE == 2 && CHUTEREL ==1 
&& AETEMP == 2 
, GPPHASE = 3] 

Iff GPPHASE == 2 && TDSENSED == 1 
, GPPHASE = 5] 

(* PHASE 4 *) 

Iff GPPHASE == 3 && GPALTO <= DROPHEIGHT 
&& TDSENSED == 0 
&& TDSSTATUS == 0 
&& XI <= MAXNORMVEL 

, GPPHASE = 4] 

Iff GPPHASE == 3 && GPALTO <= DROPHEIGHT 
&& TDSSTATUS == 1 
, GPPHASE = 5] 

Iff GPPHASE == 3 && TDSENSED == 1 
, GPPHASE = 5] 

Iff GPPHASE == 4 && TDSENSED == 1 
, GPPHASE = 5] 

Iff GPPHASE == 4 && TDSSTATUS == 1 
, GPPHASE = 5] 


(* Determine the value of CL *) 


(* CL = 1: First *) 

(* CL = 2: Second *) 


(* The difference has to be used in for comparisons in Mathematica model. *) 
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(* because the model uses approximations upto 30 digits. *) 
diff = .00000001 

od = N[OPTVEL - DROPSPEED, 30] 

Print [StringForm["od = od]] 

Print [ StringF orm[ "GP VEL0 [[1,1]] = GPVEL0[[1,1]]]] 

Print [ StringF orm[ "OPT VEL = "", OPTVEL]] 

Print [ StringF orm[ "TEI = "",TEI]] 

Print [StringForm["DROPSPEED = DROPSPEED]] 

duml = DROPSPEED 

duml = N[GPVEL0[[1,1]] - duml, 30] 

dum2 = 0. 

Print [StringForm["duml = duml]] 

If[CL = 1, Print [StringForm["test : cl = 1"]]] 

If[(Abs[od] <= diff). Print [StringForm["test : Abs(od) <= diff’]]] 

If[duml < dum2. Print [StringForm["(GPVEL0[[l,l]] < DROPSPEED)"]]] 


IfICL == 1 && Abs[od] <= diff && duml < dum2, 

CL = 2; 

TEI = 0.0 

] 

Print [StringForm["od = od]] 

Print [ StringF orm[ "GP VEL0 [[1,1]] = GPVEL0[[1,1]]]] 

Print [ StringF orm[ "OPTVEL = "", OPTVEL]] 

Print [StringForm["CL = "", CL]] 

Print [ StringF orm[ "TEI = "",TEI]] 


A-108 



GSP 


Filename : gsp.m 

Create Date : 6-30-94 
Description: 

This file contains the Mathematica code to calculate expected values 
for GSP functional unit. The following assumptions are made: 
data related to the 4 GCS data stores are pre-loaded, 
the specific data for a test case is also loaded 

(* Local variables added for readability *) 
healthy = 0 (* used for GSTATUS *) 

failed = 1 (* used for G_STATUS *) 

(**** Rotate history variables ****) 

(* GROTATION *) 

GROT4 = GROT3 
GROT3 = GROT2 
GROT2 = GROT 1 
GROT1 = GROTO 

(**** Adjust A_GAIN() for temperature ****) 

ggain = { GGAIN0[[1]] + G3 ATMTEMP + G4 ATMTEMP A 2 (* x axis *) 
,GGAIN0[[2]] + G3 ATMTEMP + G4 ATMTEMP A 2 (* y axis *) 
,GGAIN0[[3]] + G3 ATMTEMP + G4 ATMTEMP A 2 (* z axis *) 

} 

(**** Convert GCOUNTER to G ROTATION ****) 

For[ i=l, i<=3, i++, 

If [ (GCOUNTER[[i]j > 0) (* Get G COUNTER sign *) 

, sign = 1 
, sign = -l 
]; 

counter = sign Mod[GCOUNTER[[i]], 2 A 14]; (* Get lower 14 bits *) 

GROTO[[i]] = GOFFSET[[i]] (* Calculate G ROTATION *) 

+ ggain[[i]] counter 

] 

(**** Set Gyroscope status to healthy ****) 

GSTATUS = healthy 
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RECLP 




(* Filename : reclp.tc.code *) 

(■* 

(* Description: *) 

(■* 

(* This file contains the Mathematica code to calculate the expected values *) 

(* for RECLP. *) 

(* The following assumptions are made: *) 

(* 1) the data related to the 4 GCS data stores are pre-loaded *) 

(* 2) the specific data for a test case is also loaded *) 




Print [ALPHA] 
GROTO[[1]] = GROT 

GPALTO = GPALT[[1]] 
GPALT1 = GPALT[[2]] 
GPALT2 = GPALT[[3]] 
GPALT3 = GPALT[[4]] 
GPALT4 = GPALT[[5]] 


(* compute the new value of THETA *) 


DG =N[DELT*GROT] 
THETA = N[THETA + DG] 


(* check for all areas *) 


If[Abs[THETA] <= THETA1, ITH = 1, ITH = 0] 

If[Abs[THETA] <= THETA2 && Abs [THETA] > THETA1, ITH = 2] 
If[Abs[GROT] <= PI, IP = 1, IP = 0] 

If[Abs[GROT] <= P2 && Abs[GROT] > PI, IP = 2] 

If[Abs[GROT] <= P3 && Abs[GROT] > P2, IP = 3] 

If[Abs[GROT] <= P4 && Abs[GROT] > P3, IP = 4] 

If[GROT > 0. && IP == 1 && THETA > 0. && ITH == 1, IROLL = 1, IROLL = 0] 
If[GROT > 0. && IP == 1 && THETA > 0. && ITH == 2, IROLL = 3] 

If[GROT > 0. && IP == 1 && THETA > 0. && ITH == 0, IROLL = 7] 

If[GROT > 0. && IP <= 3 && THETA < 0. && ITH == 0, IROLL = 6] 

If[GROT > 0. && IP <= 3 && THETA < 0. && ITH != 0, IROLL = 1] 

If[GROT > 0. && IP == 2 && THETA > 0. && ITH != 0, IROLL = 5] 

If[GROT > 0. && IP == 2 && THETA > 0. && ITH == 0, IROLL = 7] 

If[GROT > 0. && IP >= 3 && THETA > 0., IROLL = 7] 

If[GROT > 0. && IP == 4 && THETA <= 0., IROLL = 1] 

If[GROT > 0. && IP == 0, IROLL = 7] 

If[GROT < 0. && IP <= 3 && THETA > 0. && ITH != 0, IROLL = 1] 
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IfIGROT < 0. && IP <= 3 && THETA > 0. && ITH == ■ 
IfIGROT < 0. && IP == 1 && THETA < 0. && ITH == 
IfIGROT < 0. && IP == 1 && THETA < 0. && ITH == 
IfIGROT < 0. && IP == 1 && THETA < 0. && ITH == 

IfIGROT < 0. && IP == 2 && THETA < 0. && ITH <= 
IfIGROT < 0. && IP == 2 && THETA < 0. && ITH == 

IfIGROT < 0. && IP >= 3 && THETA < 0., IROLL = 6] 

IfIGROT < 0. && IP == 4 && THETA > 0., IROLL = 1] 

IfIGROT < 0. && IP == 0, IROLL = 6] 

IfITHETA == 0. && IP != 0, IROLL = 1] 

IfITHETA == 0. && IP == 0 && GROT > 0., IROLL = ' 
IfITHETA == 0. && IP == 0 && GROT < 0., IROLL = f 

IfIGROT — 0. && AbsfTHETA] <= THETA2, IROLL = 
IfIGROT — 0. && THETA > THETA2, IROLL = 7] 
IfIGROT — 0. && THETA < -THETA2, IROLL = 6] 


i, IROLL = 7] 
, IROLL = 1] 
IROLL = 2] 
i, IROLL = 6] 

IROLL = 4] 
i, IROLL = 6] 
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TDLRSP 


Filename : tdlrsp.m 

Create Date : 6-30-94 
Description: 

This file contains the Mathematica code to calculate expected values 
for TDLRSP functional unit. The following assumptions are made: 

1) data related to the 4 GCS data stores are pre-loaded. 

2) the specific data for a test case is also loaded 
History: 

6-30-94 VO created 

3-30-95 VI Removed the use of KonAxisOK varaible 

debug =1 (* debug prints l=on 0=0ff *) 

(* Local variables added for readability *) 
healthy = 0 (* used for TDLRSTATUS *) 

failed = 1 (* used for TDLR STATUS *) 

unlocked = 0 (* used for TDLRSTATE *) 

locked = 1 (* used for TDLR STATE *) 

good =1 (* used for deciding whether KonAxis is OK *) 

bad =0 (* used for deciding whether KonAxis is OK *) 

(**** Rotate history variables ****) 

(* TDLR VELOCITY *) 

TDLRVEL4 = TDLRVEL3 
TDLRVEL3 = TDLRVEL2 
TDLRVEL2 = TDLRVEL1 
TDLRVEL1 = TDLRVEL0 

(* KMATRIX *) 

KMATRIX4 = KMATRIX3 
KMATRIX3 = KMATRIX2 
KMATRIX2 = KMATRIX 1 
KMATRIX 1 = KMATRIX0 

If [ debug==l, Print[" starting kmatrix = ",MatrixForm[KMATRIX0] ] ] 

(**** Determine radar beam status ****) 

If [debug==l, Print[" — evaluate beam — "] ] 

For [ i=l, i<=4, i++, 

If [debug==l, Print["TDLRSTATE[",i,"] = ",TDLRSTATE[[i]] ] ]; 

If [debug==l, Print["TDLRCOUNT[",i,"] = ",TDLRCOUNT[[i]] ] ]; 

If [debug==l, Print["FRBUNLOCK[",i,"] = ",FRBUNLOCK[[i]] ] ]; 

If [debug==l, Print["FRAMECOUNTER = ", FRAMECOUNTER ] ]; 
Which[ 

(* Row 1 of table 5.11 *) 

(TDLRSTATE[[i]] == locked) 

&& (TDLRCOUNT[[i]J == 0) 

, TDLRSTATE[[i]] = unlocked; 

FRBUNLOCK[[i]] = FRAMECOUNTER; 

If [debug==l, Print["Table 5.11 Row 1"] ] 

(* Row 2 of table 5.11 *) 
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, (TDLRSTATE[[i]] = unlocked) 

&& (TDLRCOUNT[[i]J != 0) 

&& ((DELTAT (FRAMECOUNTER - FRBUNLOCK[[i]])) >= TDLRLT) 
, TDLRSTATE[[i]] = locked; 

If [debug=l, Print["Table 5.11 Row 2"] ] 

(* Row 3 of table 5.11 *) 

, (TDLRSTATE[[i]] == unlocked) 

&& (TDLRCOUNT[[i]] == 0) 

&& ((DELTAT (FRAMECOUNTER - FRBUNLOCK[[i]])) >= TDLRLT) 
, FRBUNLOCK[[i]] = FRAMECOUNTER; 

If [debug=l, Print["Table 5.11 Row 3"] ] 

]; 

If [ debug==l, Print["Frame_beam_unlocked[",i,"] = ",FRBUNLOCK[[i]] ]] 

] 


If [ debug==l, Print["at 2 kmatrix = ",MatrixFonn[KMATRIXO] ] ] 
(**** Determine beam velocity ****) 

B = { N[(TDLROFF + TDLRGAIN TDLRCOUNT[[1]]),30] 
,N[(TDLROFF + TDLRGAIN TDLRCOUNT[[2]]),30] 
,N[(TDLROFF + TDLRGAIN TDLRCOUNT[[3]]),30] 
,N[(TDLROFF + TDLRGAIN TDLRCOUNT[[4]]),30] 

} 

If [ debug==l, Print["B = ",B] ] 


If [ debug==l, Print["at 3 k matrix = ",MatrixForm[KMATRIXO] ] ] 

(**** Process the beam velocities ****) 

(* NOTE: In Mathematica, the WHICH statement works like a Pascal CASE *) 
BonAxis = { 0, 0, 0 } (* case where none or only 1 beam is locked *) 

KonAxis = { 0, 0, 0 } 

Which[ TDLRSTATE[[1]] == TDLRSTATE[[2]] == TDLRSTATE[[3]] 

== TDLRSTATE[[4]] == locked 
, N[ BonAxis[[l]] = ( B[[l]] + B[[2]] + B[[3]] + B[[4]] )/4, 30]; 

N[ BonAxis[[2]] = ( B[[l]] - B[[2]] - B[[3]] + B[[4]] )/4, 30]; 

N[ BonAxis[[3]] = ( B[[l]] + B[[2]] - B[[3]] - B[[4]] )/4, 30]; 
KonAxis = { 1, 1, 1 }; 

(*V1 KonAxisOK = good; *) 

If [ debug==l, Print["Row 16"] ] 

,TDLRSTATE[[2]] == TDLRSTATE[[3]] == TDLRSTATE[[4]] == locked 
, N[ BonAxis[[l]] = ( B[[2]] + B[[4]] )/2, 30]; 

N[ BonAxis[[2]] = ( B[[4]] - B[[3]] )/2, 30]; 

N[ BonAxis[[3]] = ( B[[2]] - B[[3]] )/2, 30]; 

KonAxis = { 1, 1, 1 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 15"] ] 

,TDLRSTATE[[1]] == TDLRSTATE[[3]] == TDLRSTATE[[4]] == locked 
, N[ BonAxis[[l]] = ( B[[l]] + B[[3]] )/2, 30]; 

N[ BonAxis[[2]] = ( B[[4]] - B[[3]] )/2, 30]; 

N[ BonAxis[[3]] = ( B[[l]] - B[[4]] )/2, 30]; 

KonAxis = { 1, 1, 1 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 14"] ] 

,TDLRSTATE[[1]] == TDLRSTATE[[2]] == TDLRSTATE[[4]] == locked 
, N[ BonAxis[[l]] = ( B[[2]] + B[[4]] )/2, 30]; 

N[ BonAxis[[2]] = ( B[[l]] - B[[2]] )/2, 30]; 

N[ BonAxis[[3]] = ( B[[l]] - B[[4]] )/2, 30]; 

KonAxis = { 1, 1, 1 }; 
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(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 13”] ] 

,TDLRSTATE[[1]] == TDLRSTATE[[2]] == TDLRSTATE[[3]] == locked 
, N[ BonAxis[[l]] = ( B[[l]] + B[[3]] )/2, 30]; 

N[ BonAxis[[2]] = ( B[[l]] - B[[2]] )/2, 30]; 

N[ BonAxis[[3]] = ( B[[2]] - B[[3]] )/2, 30]; 

KonAxis = { 1, 1, 1 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 12"] ] 

,TDLRSTATE[[3]] == TDLRSTATE[[4]] == locked 
, N[ BonAxis[[2]] = ( B[[4]] - B[[3]] )/2, 30]; 

KonAxis = { 0, 1, 0 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 11"] ] 

,TDLRSTATE[[2]] == TDLRSTATE[[4]] == locked 
, N[ BonAxis[[l]] = ( B[[2]] + B[[4]] )/2, 30]; 

KonAxis = { 1, 0, 0 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 10"] ] 

,TDLRSTATE[[2]] == TDLRSTATE[[3]] == locked 
, N[ BonAxis[[3]] = ( B[[2]] - B[[3]] )/2, 30]; 

KonAxis = { 0, 0, 1 } ; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 9"] ] 

,TDLRSTATE[[1]] == TDLRSTATE[[4]] == locked 
, N[ BonAxis[[3]] = ( B[[l]] - B[[4]] )/2, 30]; 

KonAxis = { 0, 0, 1 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 8"] ] 

,TDLRSTATE[[1]] == TDLRSTATE[[3]] == locked 
, N[ BonAxis[[l]] = ( B[[l]] + B[[3]] )/2, 30]; 

KonAxis = { 1, 0, 0 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print[ "Row 7"] ] 

,TDLRSTATE[[1]] == TDLRSTATE[[2]] == locked 
, N[ BonAxis[[2]] = ( B[[l]] - B[[2]] )/2, 30]; 

KonAxis = { 0, 1, 0 }; 

(* VI KonAxisOK = good; *) 

If [ debug==l, Print["Row 6"] ] 

] 

If [ debug==l, Print["at 4 k matrix = ",MatrixForm[KMATRIX0] ] ] 

(**** Convert to body velocities ****) 

For[ i=l, i<=3, i++, (* RAD angles *) 

TDLRVEL0[[i,l]] = N[(BonAxis[[i]] 1/N[ Cos[TDLRANG[[i]]],30]),30] 

] 

If [ debug=l, Print["tdlr_velocity = "JDLRVEL0] ] 

(**** Set values in K MATRIX ****) 

^ H 4 -k -k -k -k -k »k -k »k -k -k -k »k »k -k -k -k qJ^J CO(lC fTOITl ^^0 *5* H* H* H* *k H* *k *k H* ^ 

(*If [KonAxisOK *) 

(* , KMATRIX0 = { {0,0,0}, {0,0,0}, {0,0,0} }; *)(* initialize K MATRIX *) 

(* KMATRIX0[[l,l]] = KonAxis[[l]]; *) 

(* KMATRIX0[[2,2]] = KonAxis[[2]]; *) 

(* KMATRIX0[[3,3]] = KonAxis[[3]] *) 

(* 1 *) 
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(* new code for VI *) 

If [ debug=l, Print["KonAxis = ",KonAxis] ] 

KMATRIXO = { {0,0,0}, {0,0,0}, {0,0,0} } (* initialize KMATRIX *) 
KMATRIX0[[1,1]] = KonAxis[[l]] 

KMATRIX0[[2,2]] = KonAxis[[2]] 

KMATRIXO [[3,3]] = KonAxis[[3]] 

If [ debug=l, Print ["kmatrix = ",MatrixForm[KMATRIXO] ] ] 

(**** Set TDLR STATUS to healthy ****) 

For[ i=l, i<=4, i++, 

TDLRSTATUS[[i]] = healthy 

] 
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TDSP 


Filename : tdspsp.m 

Create Date : 7-5-94 
Description: 

This file contains the Mathematica code to calculate expected values 
for TDSP functional unit. The following assumptions are made: 
data related to the 4 GCS data stores are pre-loaded, 
the specific data for a test case is also loaded 

(* Local variables added for readability *) 
healthy = 0 (* used for TDS_STATUS *) 

failed = 1 (* used for TDS_STATUS *) 

sensed =1 (* used for TDSENSED *) 

notsensed =0 (* used for TD SENSED *) 

allzeros = 0 (* used for TDCOUTNER *) 

allones =65536 (* used for TD COUTNER *) 

(**** Determine status of touch down sensor & whether it has been sensed ****) 
If[ (TDS STATUS == healthy) 

, Switch [ TDCOUTNER 
, allzeros, TDSENSED = notsensed 
, allones, TDSENSED = sensed 
TDSENSED = notsensed; 

TDS STATUS = failed 

] 

, (* according to the Spec: 

if TDS STATUS failes, GP determins when touch down occures *) 

] 
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TSP 


Filename : tsp.m 

Create Date : 7-5-94 
Description: 

This file contains the Mathematica code to calculate expected values 
for TSP functional unit. The following assumptions are made: 
data related to the 4 GCS data stores are pre-loaded, 
the specific data for a test case is also loaded 

(* Local variables added for readability *) 
healthy = 0 (* used for TS_STATUS *) 

failed = 1 (* used for TS_STATUS *) 

(**** Calculate the solid state temperature ****) 

SSslope = (T2 - Tl) / (M2 - Ml) 

SSyint = T1 - (SSslope Ml) 
sst = (SSslope SSTEMP) + SSyint 


(**** Determine upper and lower range of thermocouple temperature ****) 

LowerLimit = M3 - ( 0.15 (M4 - M3) ) (* lower bound for valid THERMO TEMP *) 

UpperLimit = M4 + ( 0.15 (M4 - M3) ) (* upper bound for valid THERMO TEMP *) 

THslope = (T4 - T3) / (M4 - M3) (* THERMO TEMP linear range slope *) 

THyint = T3 - (THslope M3) 

hL = M3 + (THslope/2) 

kL = T3 + (THslope/2) A 2 

LowerParaTemp = - ( LowerLimit - hL ) A 2 + kL 

hU = M4 - (THslope/2) 

kU = T4 - (THslope/2) A 2 

UpperParaTemp = ( UpperLimit - hU ) A 2 + kU 


(**** Determine which sensor to use, & calculate thermo-temp if necessary ****) 
If[ (sst < LowerParaTemp) || (sst > UpperParaTemp) 

, ATMTEMP = sst 

, Which[(THERMOTEMP >= M3) && (THERMOTEMP <= M4) 

, ATMTEMP = (THslope THERMOTEMP) + THyint 
JHERMOTEMP < M3 

,ATMTEMP = - (THERMOTEMP - hL) A 2 + kL 
JHERMOTEMP > M4 

,ATMTEMP = (THERMOTEMP - hU ) A 2 + kU 

] 


(**** Set both elements of TS STATUS to healthy ****) 
For[ i=l, i<=2, i++, 

TSSTATUS[[i]] = healthy 

] 

(* debug use only *) 
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(* 

Print ["sstemp = ",sst] 

Print ["UpperParaTemp = ",UpperParaTemp] 
Print ["LowerParaTemp = ",LowerParaTemp] 
Print ["Atm Temp = ",ATMTEMP] 

*) 
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A.14 Sample Test Case 


This section contains an example of a test case input file and an expected values file. Both 
are generated by Mathematic a based on the inputs that the Verification Analyst selects for the 
particular test case. Each of these files are simply a series of FORTRAN namelists that the Test 
Case Driver will use as input. The full test case consists of a Test case file and an expected- 
results file with the following naming convention: 

Test case input file: functional unit name> _<NR or RO>_<a unique number>. TC 

Expected-results file: functional unit name> _<NR or RO> _<a unique number> .EX 

Both files are needed to run the test case. The NR designation indicates a “normal range” test of 
all valid values, both input and output. The RO designation indicates a “robustness” test case. 
These include those instances where the input is valid, but an invalid output occurs, as well as 
invalid input cases. Each “robustness” test case tests only one invalid input, but a single invalid 
input may produce several invalid outputs. 

Note that this is a functional unit test case example only. The test case input files and 
expected results files for CP are generated on the VAX and not by Mathematica. Additionally, 
the subframe and frame test cases differ in that the expected values of the data element 
"PACKET" is not generated until the test case is actually executed. The example follows: 

Sample Test Case Input 


* File: gp_nr_001.tcNull 

* Date of Mathematica Model Run: 9-7-1994 

* Time of Mathematica Model Run: 8:13:5 

* Description: 

* Tester: Debbie Taylor (CSC CORP) 

* DATE: July 15, 1994 

* Unit Test for Functional Unit GP 

* 

* Test case 1 

* Initial GP Frame 

* All valid inputs 

* 

* Tests Equivalence Classes: AACCELERATION. 1 

* GPALTITUDE . 1 

* GPATTITUDE. 1 

* GPVELOCITY. 1 

* GROTATION . 1 

* TDLRVELOCITY. 1 

* 
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$RUN_PARAMETERS_NML 
A BIAS = -20., -20., -20., 

A_GAIN_0 = 0.012, 0.012, 0.012, 

AS GALE = 1, 

ALPHA _MATRIX = 

0 , 0 , 

1 , 0 , 

0 , 1 , 

ARFREQUEN CY = 2.45e9, 

COMMS YN CP ATTERN = -9806, 
CONTOURALTITUDE = -0.01, 

0.003048, 0.018288, 0.019, 0.0196, 0.0225, 
0.02617, 0.03648, 0.0506, 0.06855, 0.0903, 
0.14542,0.21583,0.30145,2., 0., 
CONTOURVELOCITY = 0.002, 

0.002, 0.002, 0.0031, 0.0035, 0.0046, 
0.00538, 0.01222, 0.0162, 0.0203, 0.0245, 
0.0333, 0.0427, 0.0528, 0.1225, 0., 
DELTAT = 0.02, 

DROPHEIGHT = 1., 

DROPSPEED = 2., 

ENGINE SONALTITUDE = 1500., 
FULLUPTIME = 5., 

G1 = 6.67e-7, 

G2 = 4.e-9, 

G3 = 3.e-9, 

G4 = 2.22e-l 1, 

G GAIN 0 = 0.0003, 0.0003, 0.0003, 

G OFFSET = 0., 0., 0., 

GA = 0.01, 

GAX = 3., 

GP1 =0.852, 

GP2 = -0.426, 

GPY = 0.892, 

GQ = 3., 7., 

GR = 3. ,7., 

GRAVITY = 3.75, 

GV = 5. ,7., 

GVE = 200., 

GVEI = 40., 20., 

GW = 5. ,7., 

GWI = 0.5,1., 

Ml = 10000., 

M2 = 10040., 

M3 = 1000., 

M4= 1010., 

MAXN ORM ALVELOCIT Y = 3.35, 
OMEGA =1., 

PI =0.00354, 

P2 = 0.00827, 

P3 = 0.01, 

P4 = 0.015708, 

PEMAX = 0.524,0.062, 

PEMIN = -0.524,-0.062, 

T1 =-200., 

T2 = 200., 
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T3 = -38.46, 

T4 = 38.46, 

TDLR_ANGLES = 0.361367,1.31812, 1.31812, 
TDLR_GAIN = 0.015625, 
TDLRLOCKTIME = 0, 

TDLROFFSET = -100., 

TEDROP = 0.1, 

TEINIT = 0.1, 

TEMAX = 0.9,0.498, 

TEMIN = 0.1, 0.1, 

THETA1 =0.004363, 

THETA2 =0.006109, 

YEMAX = 0.524,0.042, 

YEMIN = -0.524,-0.042, 

Send 


SEXTERNALNML 
ACOUNTER = 1665, 1524, 1524, 

AE CMD = 0, 0, 0, 

ARCOUNTER = 24464, 

FRAMECOUNTER = 1, 

GCOUNTER = 292, 161,7, 

PACKET = 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 

RECMD = 1, 

SSTEMP = 0., 

SUBFRAMECOUNTER = 1, 

TDCOUNTER = 0, 

TDLR COUNTER = 9920, 9770, 9852, 10002, 
THERMO_TEMP = 992, 

Send 


SSENSOROUTPUTNML 
AACCELERATION = 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

AR_ALTITUDE= 1497.79591836735, 1497.81166815946, 1497.81166815946, 1497.81166815946, 
1497.81166815946, 

ATMOSPHERIC_TEMP = -147.586, 

GROTATION = 

0.087614454, 0.0483079695, 0.0021003465, 
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0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

TDSENSED = 0, 

TDLRVELOCITY = 

58.2295430434468, 4.68750002153857, -2.56250001 177442, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

Send 

SGUIDANCESTATENML 
A_STATUS = 

0 , 0 , 

0 , 0 , 

0 , 0 , 

0 , 0 , 

AESTATUS = 0, 

AESWITCH = 0, 

AETEMP = 0, 

ARSTATUS = 0, 0, 0, 0, 0, 

CSTATUS = 0, 

CHUTERELEASED = 0, 

CL = 1, 

CONTOURCROSSED = 0, 

FRAMEBEAMUNLOCKED = 

0, 0, 0, 

FRAMEENG1NESIGNITED = 1, 

GSTATUS = 0, 

GP_ALTITUDE= 1497.81166815946, 1497.81166815946, 1497.81166815946, 1497.81166815946, 
1497.81166815946, 

GPATTITUDE = 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

GPPF1ASE = 1, 

GPROTATION = 

, -0.00210035, 0.0483079695, 

0.0021003465, 0., -0.0876145, 

-0.048308,0.087614454,0., 

GPVELOCITY = 

58.2371395855674, 4.67148327843904, -2.55368425934921, 
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58.2371395855674, 4.67148327843904, -2.5536842534921, 

58.2371395855674, 4.67148327843904, -2.55368425934921, 

58.2371395855674, 4.67148327843904, -2.55368425934921, 

58.2371395855674, 4.67148327843904, -2.55368425934921, 
INTERN ALCMD = 0, 0, 0, 

KALT = 1, 1, 1, 1, 1, 

KMATRIX = 

, 0 ., 0 ., 

, 1 ., 0 ., 

, 0 ., 1 ., 

, 0 ., 0 ., 

,1.,0„ 

, 0 ., 1 ., 

, 0 ., 0 ., 

, 1 ., 0 ., 

, 0 ., 1 ., 

, 0., 0., 

, 1 ., 0., 

, 0 ., 1 ., 

, 0., 0., 

, 1 ., 0 ., 

, 0 ., 1 „ 

PEINTEGRAL = 0., 

RESTATUS = 0, 

RES WITCH = 1, 

TDLRSTATE = 1, 1, 1, 1, 

TDLR STATUS = 0, 0, 0, 0, 

TDSSTATUS = 0, 

TEINTEGRAL = 0., 

TELIMIT = 0., 

THETA = 0.00257, 

TS STATUS = 0, 0, 

VELOCITYERROR = -43.348030923942914, 
YEINTEGRAL = 0., 

SEND 
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Sample Expected Results 


* File: gp_nr_001.exNull 

* Date of Mathematica Model Run: 9-7-1994 

* Time of Mathematica Model Run: 8:13:10 

* Description: 

* Tester: Debbie Taylor (CSC CORP) 

* DATE: July 15, 1994 

* Unit Test for Functional Unit GP 

* 

* Test case 1 

* Initial GP Frame 

* All valid inputs 

* 

* Tests Equivalence Classes: A ACCELERATION. 1 

* GPALTITUDE . 1 

* GPATTITUDE . 1 

* GPVELOCITY. 1 

* GROTATION. 1 

* TDLRVELOCITY. 1 

* 


$EX_RUN_PARAMETERS_NML 
EX A BIAS = -20., -20., -20., 

EX A GAIN O = 0.012, 0.012, 0.012, 
EXASCALE = 1, 
EXALPHAMATRIX = 

0 , 0 , 

1 , 0 , 

0 , 1 , 

EXARFREQUENCY = 2.45e9, 
EXCOMMS YN CPATTERN = -9806, 
EXCONTOURALTITUDE = -10., 
3.048, 18.288, 19., 19.6, 22.5, 
26.17,36.48,50.6, 68.55, 90.3, 

, 145.42,215.83, 301.45,2000., 0., 
EXCONT OURVELOCIT Y = 2., 

,2., 2., 3.1, 3.5, 4.6, 

5.38, 12.22, 16.2, 20.3, 24.5, 
33.3,42.7, 52.8, 122.5,0., 
EXDELTAT = 0.02, 
EX_DROP_HEIGHT = 1., 
EXDROPSPEED = 2., 
EXENGINESONALTITUDE = 1500., 
EXFULLUPTIME = 5., 

EXGl = 6.67e-7, 

EXG2 = 4.e-9, 

EXG3 = 3.e-9, 

EXG4 = 2.22e-ll, 

EX G GAIN 0 = 0.0003, 0.0003, 0.0003, 
EX G OFFSET = 0., 0., 0., 
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EXGA = 0.01, 

EXGAX = 3., 

EXGPl =0.852, 

EXGP2 = -0.426, 

EXGPY = 0.892, 

EX GQ = 3., 7., 

EXGR = 3. ,7., 

EXGRAVITY = 3.75, 

EXGV = 5., 7., 

EXGVE = 200., 

EXGVEI = 40. ,20., 

EXGW = 5. ,7., 

EX_GWI = 0.5,1., 

EXMl = 10000., 

EX_M2 = 10040., 

EXM3 = 1000., 

EX_M4= 1010., 

EXMAXN ORMALVELOCIT Y = 3.35, 
EXOMEGA = 1 ., 

EX_P1 =0.00354, 

EXP2 = 0.00827, 

EXP3 = 0.01, 

EX_P4 = 0.015708, 

EXPEMAX = 0.524,0.062, 

EXPEMIN = -0.524,-0.062, 

EXTl =-200., 

EXT2 = 200., 

EXT3 = -38.46, 

EXT4 = 38.46, 

EXTDLRAN GLE S = 0.361367,1.31812, 1.31812, 
EXTDLRGAIN = 0.015625, 
EXTDLRLOCKTIME = 0, 

EXTDLROFFSET = -100., 

EXTEDROP = 0.1, 

EXTEINIT = 0. 1, 

EXTEMAX = 0.9,0.498, 

EXTEMIN = 0. 1 ,0. 1 , 

EXTHETAl = 0.004363, 

EXTHETA2 = 0.006109, 

EXYEMAX = 0.524,0.042, 

EXYEMIN = -0.524,-0.042, 

Send 

SEXEXTERNALNML 
EX_A_COUNTER= 1665, 1524, 1524, 

EX AE CMD = 0, 0, 0, 

EXARCOUNTER = 24464, 
EXFRAMECOUNTER = 1, 

EXGCOUNTER = 292, 161,7, 

EXPACKET = 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
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0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
EXRECMD = 1, 

EXSSTEMP = 0., 

EXSUBFRAMECOUNTER = 1, 
EXTDCOUNTER = 0, 

EXTDLRCOUNTER = 9920, 9770, 9852, 10002, 
EXTHERMOTEMP = 992, 

Send 


SEXSENSOROUTPUTNML 
EXAACCELERATION = 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

1.63739825110955, -0.202263936687537, 1.99439462855677, 

EX_AR_ALTITUDE= 1497.79591836735, 1497.81166815946, 1497.81166815946, 1497.81166815946, 
1497.81166815946, 

EXATMO SPHERICTEMP = -147.586, 

EXGROT ATION = 

0.087614454, 0.0483079695, 0.0021003465, 

0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

0.0876579642295837, 0.0485167264938354, 0.00239650011062622, 

EXTDSEN SED = 0, 

EXTDLRVELOCITY = 

58.2295430434468, 4.68750002153857, -2.56250001 177442, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

58.2371395855674, 58.2371395855674, 58.2371395855674, 

Send 


SEXGUID AN CEST ATENML 
EX_A_ST ATU S = 

0 , 0 , 

0 , 0 , 

0 , 0 , 

0 , 0 , 

EXAESTATUS = 0, 

EXAES WITCH = 1, 
EXAETEMP = 0, 

EX AR STATUS = 0, 0, 0, 0, 0, 
EXCST ATU S = 0, 
EXCHUTERELEASED = 0, 
EXCL = 1 , 

EXCONTOURCROSSED = 0, 
EXFRAMEBEAMUNLOCKED = 
0 , 0 , 0 , 
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EX FRAME ENGINESJGNITED = 1, 

EXGSTATUS = 0, 

EX_GP_ALTITUDE = 1495.521749022006, 1497.81166815946, 1497.81166815946, 1497.81166815946, 
1497.81166815946, 

EXGPATTITUDE = 

-0.03979878822126675, 0.957525014194865, -0.2855904474112915, 

-0.07660037852440182, 0.282052052010574, 0.956336249426609, 

0.99626725253411, 0.05993736023322743, 0.06212144864759948, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

-0.0404392391645691, 0.958516512228094, -0.282153794448846, 

-0.0747709982983742, 0.278690021002445, 0.957466015066395, 

0.99638043223924, 0.0598161180598313, 0.0603992240926737, 

EXGPPH A S E = 2, 

EXGPROT ATION = 

, -0.00210035, 0.0483079695, 

0.0021003465, 0., -0.0876145, 

-0.048308,0.087614454,0., 

EXGPVELOCITY = 

58.45070383441093, 6.40601755948299, -0.3969432260435215, 

58.2371395855674, 4.67148327843904, -2.55368425934921, 

58.2371395855674, 4.67148327843904, -2.5536842534921, 

58.2371395855674, 4.67148327843904, -2.55368425934921, 

58.2371395855674, 4.67148327843904, -2.55368425934921, 

EX INTERNAL CMD = 0, 0, 0, 

EXKALT = 1, 1, 1, 1, 1, 

EXKMATRIX = 

, 0 ., 0 ., 

, 1 , 0 ., 

, 0 ., 1 ., 

, 0 ., 0 ., 

, 1 ., 0 ., 

, 0 ., 1 ., 

, 0 ., 0 ., 

, 1 ., 0., 

, 0 ., 1 ., 

, 0 ., 0 ., 

, 1 ., 0 ., 

, 0 ., 1 ., 

, 0 ., 0 ., 

, 1 ., 0., 

, 0 ., 1 ., 

EXPEINTEGRAL = 0., 

EXRESTATUS = 0, 

EXRES WITCH = 1, 

EXTDLRSTATE = 1, 1, 1, 1, 

EX TDLR STATUS = 0, 0, 0, 0, 

EXTD S_ST ATU S = 0, 

EXTEINTEGRAL = 0., 
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EXTELIMIT = 0., 

EXTHETA = 0.00257, 

EXTSSTATUS = 0, 0, 

EXVELOCITYERROR = -43.34803091395316, 
EXYEINTEGRAL = 0., 

SEND 


A.15 Sample Test Stub 

The Test stubs are simply FORTRAN shells that will call the source code for each functional 
unit. These shells are compiled and linked with the source code provided by the programmer. 
The resulting executable code is then run at least once for each test case. The drivers compare the 
data in the expected-results files to the actual data computed by the source code and prints out a 
file that prints the discrepancies. 


C 

C NAME: test gp.for 
C 

C DATE: 12/29/94 
C 

C PURPOSE: Generic test driver for GCS Guidance Processing 
C module. Reads in a test case data file, *.TC, executes 

C the module to be tested, and compares the actual computed data to 

C the expected data in file, *.EX 
C 

program test_gp 

include 'struct. for_inc' 
include 'commons, for inc/nolist' 

C 

C List of module inputs 


namelist /EXTERNAL NML/ 

+ A COUNTER, AE CMD, AR COUNTER, FRAME COUNTER, 

+ G_COUNTER,PACKET, RECMD, S S TEMP, SUBFRAME COUNTER, 

+ TD COUNTER, TDLR COUNTER, THERMO TEMP 
C 

namelist /SENSOR_OUTPUT_NML/ 

+ A ACCELERATION, AR ALTITUDE, ATMOSPHERICTEMP, G ROTATION, 
+ TD SENSED, TDLR VELOCITY 
C 

namelist /GUIDANCE_STATE_NML/ 

+ A STATUS, AE STATUS, AE SWITCH, AE TEMP, AR STATUS, 

+ C STATUS, CHUTE RELEASED, CL, CONTOUR_CROSSED, 

+ FRAME BEAM UNLOCKED, FRAME ENGINES IGNITED, 

+ G STATUS, GP ALTITUDE, GP ATTITUDE, GP_PHASE, 

+ GP ROTATION, GP_VELOCITY, INTERN AL CMD, K ALT, 

+ K MATRIX, PE INTEGRAL, RE STATUS, RE SWITCH, TDLR STATE, 
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+ TDLRSTATUS, TDS_STATUS, TE INTEGRAL, TE LIMIT, THETA, 

+ TS_STATUS, VELOCITYERROR, YE INTEGRAL 
c 

namelist /RUNPARAMETERSNML/ 

+ ABIAS, A GA1N 0, ASCALE, ALPHA MATRIX, AR FREQUENCY, 

+ COMMSYNCPATTERN, CONTOUR ALTITUDE, CONTOUR_VELOCITY, 

+ DELTA T, DROP HEIGHT, DROP_SPEED, ENGINES ON ALTITUDE, 

+ FULLUPTIME, Gl, G2, G3, G4, G_GAIN_0, G OFFSET, GA, 

+ GAX, GP1, GP2, GPY, GQ, GR, GRAVITY, GV, GVE, GVEI, GVI, 

+ GW, GWI, Ml, M2, M3, M4, MAX N ORMAL VELOCIT Y, OMEGA, PI, 

+ P2, P3, P4, PE MAX, PE MIN, Tl, T2, T3, T4, TDLR ANGLES, 

+ TDLR GAIN, TDLR LOCK TIME, TDLR OFFSET, TE DROP, TE INIT, 

+ TE MAX, TE MIN, THETA 1, THETA2, YE MAX, YE MIN 

namelist /EX_EXTERNAL_NML/ 

+ EX A COUNTER, EX AE CMD, EX AR COUNTER, EX FRAME COUNTER, 
+ EX G COUNTER, EX PACKET, EX RE CMD, EX_SS_TEMP, 

+ EXSUBFRAMECOUNTER, 

+ EX TD COUNTER, EX TDLR COUNTER, EX THERMO TEMP 
C 

namelist /EX_SENSOR_OUTPUT_NML/ 

+ EX_ A ACCELERATION, EX AR ALTITUDE, EX ATMOSPHERIC TEMP, 

+ EXGROTATION, 

+ EX TD SENSED, EX TDLR VELOCITY 
C 

namelist /EXGUID AN CEST ATENML/ 

+ EX A STATUS, EX AE STATUS, EX AE SWITCH, EX AE TEMP, 

+ EXARSTATUS, 

+ EX C ST ATU S , EX CHUTE RELEASED, EX CL, EX_CONTOUR_CROSSED, 
+ EX FRAME BEAM UNLOCKED, EX FRAME EN GINE S IGNITED , 

+ EX G STATUS, EX GP ALTITUDE, EX GP ATTITUDE, EX_GP_PHASE, 

+ EX GP ROT ATION, EX_GP_VELOCITY, EX INTERNAL CMD, EX K ALT, 

+ EX K MATRIX, EX PE1NTEGRAL, EX RE STATUS, EX RE SWITCH, 

+ EXTDLRSTATE, 

+ EX TDLR STATUS, EX_TDS_STATUS, EX TE INTEGRAL, EX TE LIMIT, 

+ EXTHETA, 

+ EX TS STATUS, EX VELOCITY ERROR, EX YE1NTEGRAL 


C**** Begin execution 


C Read in test case data 
call read tc 


C Execute gp 

type *, 'executing gp...' 
call gp 

C Read in the expected results from the appropriate .EX fde 
call read ex 

C Compare the expected results with the actual results 
type *, 'compare guid...' 
call compare guidance 
type *, 'compare_sensor...' 
call compare sensor 
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type *, 'compare_runparam...' 
call compare runpram 

type *, 'compare extern...' 
call compare external 

C**** end execution 
end 


A.16 Test Case Results Log 


Test Case Results Log 


TEST CASE 
NAME 

EXECUTION 

DATE 

CODE 
VERSION # 

TEST CASE 
VERSION # 

RESULTS 

(was .ANA file 
generated Y or N?) 

PR# 






























































This log will trace the results of each implementation’s test runs. It serves as a history of test 
cases executions for each implementation. Due to the large number of test cases, grouping them 
logically is highly recommended. For example the Test Case Results Logs will be broken up into 
15 different logs; one for each functional unit test suite, one for each subframe test suite and one 
for the frame test suite. The title of the log will be modified to indicate which test suite and 
which implementation is being logged. For example the Test Case Log for Mercury for AECLP 
would be titled : MERCURY TEST CASE RESULTS LOG FOR AECLP . 


Each of the fields in the log are described below: 


TEST CASE NAME: 
DATE: 


CODE UNIT VERSION #: 

TEST CASE VERSION #: 

RESULTS: 

PR#: 


The name of the test case being logged 

The date the test case was run. This is used to distinguish 

between multiple runs of the same test case. 

The version of the code being tested. This is be used to 
distinguish between multiple runs of the same test case. 
The version of the test case being tested. This is be used to 
distinguish between multiple runs of the same test case. 
Was a .ANA file generated? If yes, a PR must be issued. 
The PR number generated as a result of a test failure. 
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B.l Introduction 


The purpose of this document, as described in Section 11.14 of DO-178B, is to provide details 
about the results of software verification activities conducted for the PLUTO implementation of 
the Guidance and Control Software (GCS). As stated in other documents, the GCS project 
adheres to the DO-178B guidelines for Level A software. Accordingly, specific verification 
activities have been described in the Software Verification Plan, and Software Verification Cases 
and Procedures documents. This document gives the results of each of those activities as carried 
out on the Pluto implementation. 

As stated in the Software Verification Plan, verification activities conducted for Pluto 
encompass two groups: 

• Review and analysis of artifacts from the Design and Coding processes 

• Development and execution of test cases 

The review and analysis of the Pluto design and source code are performed following the 
procedure established in the Software Verification Cases and Procedures document. Test case 
development as well as test case execution are also performed in accordance with procedures 
described in that document. The three sections below are the main thrust of this document and 
describe the design review, code review, and test case execution results. 

B.2. Review and Analysis Results 

B.2.1 Design Review 

Two reviews were held for the Pluto design. The first occurred between September 16, 1993 
and October 15, 1993. Problem Reports (PR) 1 through 13 were issued based on deficiencies 
found during this review. Before the second review, a modification to the specification (Spec. 
Mod. 2.3-2) necessitated issuance of PR 14. On July 1, 1994 an overview meeting was held for 
the Pluto design. The second design review was held twelve days later on July 13, 1994. This 
review culminated with the issuance of PRs 15 through 19. During this review, the design 
portion of the Traceability Matrix for Pluto given in section B.5 was completed. Shortly there 
after, PR 20 was issued due to another change to the GCS Specification. There after, the Pluto 
design was considered reviewed. 

B.2.2 Code Review 

Only one review was held for the Pluto code. An overview meeting occurred on October 26, 
1994. The actual code review occurred November 16, 1995. Based on the code inspection, PR 
21 through 23 were issued to correct deficiencies found. During the code review, modules of the 
code were identified with their requirements in the Pluto Traceability Matrix, see section B.5. 
The code was deemed ready for testing there after. 

B.3. Pluto Test Results 

DO-178B requires that test cases provide the coverage as stated in Section 6.4.2 and Table 
B.5-7. As described in the Verification Cases document, test cases were developed to fulfill those 
requirements. Testing Pluto with the those test cases will ensure that the coverage has been 
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satisfied for the implementation. Pluto testing proceeded in the order as specified in Software 
Verification Cases and Procedures : 


Requirements-based functional unit testing 

• Requirements-based Subframe testing 

• Requirements-based Frame testing 

• Requirements-based Trajectory testing 

• Structural analysis and testing of functional units 

The output from each test phase was a series of test logs indicating when the test cases were 
executed, and whether the test cases revealed any deficiencies. A condensed version of the test 
logs are included in the following sections. Each section starts with a list of code components 
tested and the test log for that functional unit. The test logs have been abbreviated here so that 
only the naming pattern is entered in each entry of the log. Only those test cases that failed are 
listed specifically. The full test log for each Pluto functional unit are stored and can be fetched 
from the CMS library for this project. The same naming conventions are used in the logs as are 
used in the Verification Cases document. 

The Pluto code consists of 21 files, each termed a code component. A description of each 
component is given in Table B. 1 . 


Table B.l: Description of Pluto Code Components. 


Pluto Code Component 

Functional Description 

AECLP.FOR 

Imnlements the AECLP functional unit 

ARSP.FOR 

Implements the ARSP functional unit 

ASP. FOR 

Implements the ASP functional unit 

CLPSF.FOR 

This implements the control law processing subframe 

CP. FOR 

This implements the CP functional unit 

CROP. FOR 

This implements the CRCP functional unit. 

EXTERN AL.FOR 

This is the include file for the External data store 

GP.FOR 

Implements the GP functional unit 

GPSF.FOR 

Implement the guidance processing subframe. 

GSP.FOR 

Implements the GSP functional unit 

GUIDANCE STATE.FOR 

This component is an include file for the Guidance State data store. 

PLUTO. FOR 

Implements the high level interface into the Pluto code. 

RECLP.FOR 

Implements the RECLP functional unit 

RUN PARAMETERS. FOR 

Include file for Run Parameters data store 

SENSOR OUTPUT. FOR 

Include file for Sensor Output data store 

SPSF.FOR 

This routine implements the sensor processing subframe 

TDLRSP.FOR 

Implements the TDLRSP functional unit 

TDSP.FOR 

Implements the TDSP functional unit 

TSP.FOR 

Implements the TSP functional unit 

UTILITY.FOR 

This file contains routines that perform range checking, checking for zero, and 
negative values. The routines are used in all functional units. 
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B.3.1 Requirements Based Functional Unit Testing 


The following sections gives the results of the requirements-based test cases for the Pluto 
implementation starting with the functional-unit level testing. A list of functional unit is given 
below followed by the results of each functional unit. 


Axial Engine Control Law Processing 

AECLP 

Altimeter Radar Sensor Processing 

ARSP 

Accelerometer Sensor Processing 

ASP 

Communications Processing 

CP 

Chute Release Control Processing 

CRCP 

Guidance Processing 

GP 

Gyroscope Sensor Processing 

GSP 

Roll Engine Control Law Processing 

RECLP 

Touch Down Landing Radar Sensor Processing 

TDLRSP 

Touch Down Sensor Processing 

TDSP 

Temperature Sensor Processing 

TSP 
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B.3.1.1 ARSP Functional Unit 


Code components tested in this test suite are given in Table B.2. The test log for ARSP 
requirements-based testing is summarized in Table B.3. The "xxx" notation used in Table B.3 as 
well as other test log summaries in this document represent the test case number. Only test cases 
that revealed anomalies in the code are specifically listed. 


Table B.2: ARSP code components. 


EXTERN AL.FOR 

ARSP. FOR 

RUNPARAMETERS.FOR 

UTILITY.FOR 

GUIDANCESTATE.FOR 

CONST ANTS. FOR 

SENSOROUTPUT.FOR 



Total number of normal range (NR) test cases: 9 
Total number of robustness (RO) test cases: 14 


Table B.3: Summary of Requirements-based Testing on the ARSP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA flle/PR # 

Reason for Test Run 


1/5/95 

N 

Initial testing. 



N 




Y/24 




Y/24 




Y/24 


ARS PROxxx 

1/13/95 

N 

Retesting because PR 24 changed 

ARSPNRxxx 


N 

CONSTANT.FOR. 


4/7/95 

N 

Retest after Cases & Procedures 



N 

finalized. 


Note: an analysis file (.ANA file) is only generated when the results of the test case does 
not match the expected results. In the RESULTS column in Table B.3, a "Y" indicates 
that the test cases miscompared generating an ANA file. "N" indicates cases that did not 
have any miscompares. 
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B.3.1.2 ASP Functional Unit 


Code components tested for this functional unit are given in Table B.4. 


Table B.4: ASP code components. 


EXTERN AL.FOR 

ASP. FOR 

RUNP ARAMETERS .FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SENSOROUTPUT.FOR 



Total number of normal range (NR) test cases: 8 
Total number of robustness (RO) test cases: 36 

Table B.5: Summary of Requirements-based Testing on the ASP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS .ANA 

flle/PR # 

Reason for Test Run 

ASPNRxxx 

1/5/95 

N 

Initial testing 

ASPROxxx 


N 


ASPNRxxx 

1/17/95 

N 

Retesting because PR 24 changed 

ASPROxxx 


N 

CONST ANT.FOR. 

ASPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures 

ASPROxxx 


N 

finalized. 
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B.3.1.3 GSP Functional Unit 


Code components tested in this test suite are given in Table B.6. 


Table B.6: GSP code components. 


EXTERN AL.FOR 

GSP. FOR 

RUNP ARAMETERS .FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SENSOROUTPUT.FOR 



Total number of normal range (NR) test cases: 8 
Total number of robustness (RO) test cases: 36 

Table B.7: Summary of Requirements-based Testing on the GSP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

GSPNRxxx 

1/5/95 

N 

Initial testing 

GSPROxxx 


N 


GSPNRxxx 

1/17/95 

N 

Retesting because PR 24 changed 

GSPROxxx 


N 

CONST ANT.FOR. 

GSPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures 

GSPROxxx 


N 

finalized. 
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B.3.1.4 TSP Functional Unit 


Code components tested in this suite are given in Table B.8. 


Table B.8: TSP code components. 


EXTERNAL.FOR 

TSP. FOR 

RUNPARAMETERS .FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SEN SOROUTPUT.FOR 



Total number of normal range (NR) test cases: 5 
Total number of robustness (RO) test cases: 6 

The first iteration of testing revealed some deficiencies in TSP. These were addressed in 
Problem Report 24. The second iteration of testing shows that all deficiencies were corrected 
except for TSPROOll which still did not compare exactly for ATMOSPHERICTEMP. The 
ANA file shows that Pluto computed ATMOSPHERIC TEMP to be -0.1 140537605916xl0 10 
while the expected value is -0.1 140537605916xl0 10 . Recall from the pass/fail criteria discussion 
in Software Verification Cases and Procedures that relative error is used as an accuracy check 
when ATMOSPHERIC TEMP exceeds 1. Accordingly, the absolute error is deduced to be .001 
(since the number is not printed in the ANA file to the full precision); the relative error is 
calculated to be (.001/114053760) 8.77xl0" 12 . This is less than the d for 

ATMOSPHERIC TEMP given in Table 22 of Software Verification Cases and Procedures. 
Hence this test case is considered passed. Note additionally that the value given for 
ATMOSPHERIC TEMP is also out of bounds. Thi s is also acceptable because its a robustness 
test case. 

Table B.9: Summary of Requirements-based Testing on the TSP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

TSPNRxxx 

1/4/95 

N 

Initial testing 

TSPROxxx 


N 

TSPNR 006.TC 


Y/24 

TSPNR 007.TC 


Y/24 

T SPRO 00 8 .TC 


Y/24 

TSPRO 009.TC 


Y/24 

TSPRO010.TC 


Y/24 

TSPROOll.TC 


Y/24 

TSPNRxxx 

1/13/95 

N 

Retesting due to PR 24 corrections. 

TSPROxxx 


N 

TSPROOll.TC 


Y* 

TSPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures finalized 

TSPROxxx 


N 

TSPROOll.TC 


Y* 
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B.3.1.5 TDSP Functional Unit 


Code components tested for TDSP are given in Table B.10. 


Table B.10: TDSP code components. 


EXTERN AL.FOR 

TDSP. FOR 

RUNPARAMETERS .FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SEN SOROUTPUT.FOR 



Total number of normal range (NR) test cases: 3 
Total number of robustness (RO) test cases: 4 

Table B.l 1: Summary of Requirements-based Testing on the TDSP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

TDSPNRxxx 

1/4/95 

N 

Initial testing 

TDSPROxxx 


N 


TDSPNRxxx 

1/17/95 

N 

Retesting because PR 24 changed 

TDSPROxxx 


N 

CONST ANT.FOR. 

TDSPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures 

TDSPROxxx 


N 

finalized. 
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B.3.1.6 TDLRSP Functional Unit 


Code components tested for TDLRSP are given in Table B. 12. 

Table B.12: TDLRSP code components. 


EXTERN AL.FOR 

TDLRSP.FOR 

RUNP ARAMETERS .FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SEN SOROUTPUT.FOR 



Total number of normal range (NR) test cases: 18 
Total number of robustness (RO) test cases: 10 


The ANA file generated for TDLRSPRO026 involves a condition that is not specified in the 
SPEC. Although the results of this test run does not agree with the expected values, the results 
are just as valid because this robustness test case exercises a condition that is not defined in the 
Specification. More specifically, a value of "2" is assigned to the variable TDLRSTATE. 
Although a "2" is not defined as a legal value for this variable in the GCS Spec, it is a possible 
value since the variable is ultimately implemented as an integer. For robustness test cases, DO- 
178B requires only that the software not cause any detrimental effects to the system. For this 
specific test case, the PLUTO code leaves the values of K MATRIX unchanged. This will not 
have a severe impact on the implementation's ability to deliver the required function for 
TDLRSP. 


Table B.13: Summary of Requirements-based Testing on the TDLRSP Functional Unit. 


TEST CASE 

EXECUTION 

RESULTS .ANA 

Reason for Test Run 

NAME 

DATE 

file/PR # 


TDLRSPNRxxx 

1/4/95 

N 

Initial testing 

TDLRSPROxxx 


N 


TDLRSPRO026 


Y/24 


TDLRSPNRxx 

1/13/95 

N 

Retesting due to PR 24. 

TDLRSPROxxx 


N 


TDLRSPRO026 


Y 


TDLRSPNRxx 

4/7/95 

N 

Retest after Cases & Procedures 

TDLRSPROxxx 


N 

finalized. 

TDLRSPRO026 


Y 
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B.3.1.7 GP Functional Unit 


Code components tested for GP are given in Table B. 14. 


Table B.14: GP code components. 


EXTERN AL.FOR 

GP.FOR 

RUNPARAMETERS .FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SEN SOROUTPUT.FOR 



Total number of normal range (NR) test cases: 14 
Total number of robustness (RO) test cases: 103 


In the initial run of all the GP test cases, there were some errors in the algorithm for 
calculating GPATTITUDE, GPALTITUDE, and GP VELOCITY. This caused a mismatch 
with the expected results for all the test cases. Problem Report 24 addressed this deficiency. As 
indicated in the second iteration of tests, this deficiency has been eliminated. The third run of GP 
test cases test a change to CONSTANT.FOR. 


Table B. 15: Summary of Requirements-based Testing on the GP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS .ANA 

file/PR # 

Reason for Test Run 

GPNRxxx 

1/4/95 

Y/24 

Initial testing 

GPROxxx 

1/4/95 

Y/24 

GPNRxxx 

1/13/95 

N 

Retesting after PR 24 changes 

GPROxxx 

1/13/95 

N 

GPNRxxx 

3/1/95 

N 

Retesting due to SDCR 15 

GPROxxx 

3/1/95 

N 

GPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures 
finalized. 

GPROxxx 

4/7/95 

N 
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B.3.1.8 AECLP Functional Unit 


Code components tested for AECLP are given in Table B.16. 


Table B.16: AECLP code components. 


EXTERNAL.FOR 

AECLP.FOR 

RUNPARAMETERS .FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SEN SOROUTPUT.FOR 



Total number of normal range (NR) test cases: 14 
Total number of robustness (RO) test cases: 43 


There were three iterations of testing for this functional unit as can be seen from the test log. 
Although all test cases passed in the first iteration, the second iteration was necessitated by a 
change in the CONSTANTS. FOR documented in Problem Report #24. 


Table B. 17: Summary of Requirements-based Testing on the AECLP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS .ANA 

file/PR # 

Reason for Test Run 

AECLPNRxxx 

1/5/95 

N 

Initial testing 

AECLPROxxx 


N 


AECLPNRxxx 

1/18/95 

N 

Retesting because PR 24 changed 

AECLPROxxx 


N 

CONSTANT.FOR. 

AECLPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures 

AECLPROxxx 


N 

finalized. 
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B.3.1.9 RECLP Functional Unit 


Code components tested for RECLP are given in Table B.18. 


Table B.18: RECLP code components 


EXTERNAL.F OR 

RECLP.FOR 

RUN_PARA.METERS.FOR 

UTILITY.FOR 

GUID AN CEST ATE. F OR 

CONSTANTS.FOR 

SEN SOROUTPUT.FOR 



Total number of normal range (NR) test cases: 64 
Total number of robustness (RO) test cases: 4 

For the first round of testing, even though an analysis file (.ANA) was not generated for these 
test cases, the limits checking prints messages to the screen for values of THETA that are in 
bounds. Further observations revealed that the upper and lower bounds constants were reversed 
in CONSTANTS. FOR. This has been addressed in Problem Report 24. Test cases were re- 
executed after this was corrected. Note that neither the RECLP code or the test cases had to be 
refetched. However, the CONSTANTS. FOR file was refetched and the code was recompiled to 
generate a new executable incorporating new changes from CONSTANTS.FOR. 


Table B.19: Summary of Requirements-based Testing on the RECLP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS .ANA 

file/PR # 

Reason for Test Run 

RECLPNRxxx 

1/5/95 

N/24 

Initial testing 

RECLPROxxx 


N/24 


RECLPNRxxx 

1/13/95 

N 

Retesting because PR 24 changed 

RECLPROxxx 


N 

CONSTANT.FOR. 

RECLPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures 

RECLPROxxx 


N 

finalized. 
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B. 3. 1.10 CRCP Functional Unit 


Code components tested for CRCP are given in Table B.20. 


Table B.20: CRCP code components. 


CRCP. FOR 

EXTERN AL.FOR 

UTILITY.FOR 

RUNP ARAMETERS .FOR 

CONST ANTS. FOR 

GUIDANCESTATE.FOR 


SENSOROUTPUT.FOR 


Total number of normal range (NR) test cases: 6 
Total number of robustness (RO) test cases: 4 

Table B.21: Summary of Requirements-based Testing on the CRCP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

CRCPNRxxx 

1/5/95 

N 

Initial testing 

CRCPROxxx 


N 


CRCPNRxxx 

1/17/95 

N 

Retesting because PR 24 changed 

CRCPROxxx 


N 

CONST ANT.FOR. 

CRCPNRxxx 

4/7/95 

N 

Retest after Cases & Procedure finalized. 

CRCPROxxx 


N 
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B. 3. 1.11 CP Functional Unit 


Code components tested for CP are given in Table B.22. 


Table B.22: CP code components: 


CP. FOR 

EXTERN AL.FOR 

UTILITY.FOR 

RUNP ARAMETERS .FOR 

CONST ANTS. FOR 

GUIDANCESTATE.FOR 


SENSOROUTPUT.FOR 


Total number of normal range (NR) test cases: 5 
Total number of robustness (RO) test cases: 0 

Table B.23: Summary of Requirements-based Testing on the CP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

CPNRxxx 

1/12/95 

Y/25 

Initial testing 

CPNRxxx 

1/19/95 

N 

Retesting after PR 25 modifications 

CPNRxxx 

4/7/95 

N 

Retest after Cases & Procedures finalized 
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B.3.2 Subframe Testing 


While preparing the code for subframe and frame testing, errors were found that necessitated 
issuance of PR 26. 


B.3.2. 1 SP Subframe 

Code components tested for SP subframe are given in Table B.24. 


Table B.24: SP code components. 


TSP.FOR 

EXTERN AL.FOR 

ARSP.FOR 

RUNP ARAMETERS .FOR 

ASP. FOR 

GUID AN CE ST ATE .FOR 

GSP.FOR 

SENSOROUTPUT.FOR 

TDLRSP.FOR 

CONSTANTS. FOR 

TDSP.FOR 

UTILITY.FOR 

CP. FOR 



Total number of test cases: 1 


Table B.25: Summary of Requirements-based Testing on the SP subframe. 


TEST CASE 

EXECUTION 

RESULTS 

Reason for Test Run 

NAME 

DATE 

.ANA file/PR # 


SP_001 

3/6/95 

N 

Initial testing 

SP_001 

4/7/95 

N 

Retest after Cases & Procedures finalized 
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B.3.2.2 GP Subframe 


Code components tested for GP subframe are given in Table B.26. 


Table B.26: GP subframe code components. 


GP.FOR 

EXTERN AL.FOR 

CP. FOR 

RUN PARAMETERS .FOR 

UTILITY.FOR 

GUIDANCE STATE.FOR 

CONSTANTS.FOR 

SENSOR OUTPUT. FOR 


Total number of test cases: 8 


Table B.27: Summary of Requirements-based Testing on the GPSF subframe. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

GPSFxxx 

3/6/95 

N 

Initial testing 

GPSFxxx 

4/7/95 

N 

Retest after Cases & Procedures finalized 
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B.3.2.3 CLP Subframe 


Code components tested for CLP subframe are given in Table B.28. 


Table B.28: CLP subframe code components. 


AECLP.FOR 

EXTERN AL.FOR 

RECLP.FOR 

RUNP ARAMETERS .FOR 

CRCP.FOR 

GUID AN CE ST ATE .FOR 

CP. FOR 

SENSOROUTPUT.FOR 

UTILITY.FOR 

CONSTANTS.FOR 


Total number of test cases: 14 


Table B.29: Summary of Requirements-based Testing on the CLP subframe. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

CLPxxx 

3/6/95 

N 

Initial testing 

CLPxxx 

4/7/95 

N 

Retest after Cases & Procedures finalized 
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B.3.3 Frame Testing 


Code components tested during Frame testing are given in Table B.28. 


Table B.30: Frame code components. 


TSP.FOR 

CROP. FOR 

ARSP.FOR 

CP. FOR 

ASP. FOR 

UTILITY.FOR 

GSP.FOR 

EXTERN AL.FOR 

TDLRSP.FOR 

RUNP ARAMETERS .FOR 

TDSP.FOR 

GUID AN CE ST ATE .FOR 

GP.FOR 

SENSOROUTPUT.FOR 

AECLP.FOR 

CONSTANTS. FOR 

RECLP.FOR 



Total number of test cases: 9 


Table B.31: Summary of Requirements-based Testing on for Frame. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

FRAMExxx 

3/6/95 

N 

Initial testing 

FRAMExxx 

4/7/95 

N 

Retest after Cases & Procedures finalized 
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B.3.4 Trajectory Testing 


Code components tested during trajectory testing are in Table B.32. 


Table B.32: Trajectory test code components. 


PLUTO. FOR 

AECLP.FOR 

SPSF.FOR 

RECLP.FOR 

GPSF.FOR 

CRCP.FOR 

CLPSF.FOR 

CP. FOR 

TSP.FOR 

UTILITY.FOR 

ARSP.FOR 

EXTERN AL.FOR 

ASP. FOR 

RUNPARAMETERS .FOR 

GSP.FOR 

GUID AN CE ST ATE .FOR 

TDLRSP.FOR 

SENSOROUTPUT.FOR 

TDSP.FOR 

CONSTANTS. FOR 

GP.FOR 



Total number of test cases: 34 


Table B.33: Summary of Requirements-based Trajectory Testing 


TEST CASE NAME 

EXECUTION 

DATE 

FAILED 

FRAME 

NUMBER 

MATCHES 

FAILED 
GP PHASE 
MATCHES 

Reason for Test Run 

TRAJ_ATM_UD/IC_xx 

X 

3/6/95 

N 

N 

Initial testing 

TRAJTDUD/ICxxx 


N 

N 

TRA JTDUD/ICO 1 9 


Y/27 

N 

TRA JTDUD/IC02 1 


N 

Y/27 

TRAJ_ATM_UD/IC_xx 

X 

4/7/95 

N 

N 

Retesting after PR 27 modifications. 

TRAJTDUD/ICxxx 


N 

N 
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B.3.5 Structural Analysis and Testing 

Structural analysis of Pluto source code was performed with the aid of the ACT software. 
ACT was used to derive a decision tree for each functional unit code. These trees are included 
with their respective decision tables. Decision tables were then created to match test cases to the 
specific decisions in the code. Each decision entry in a table has a true and false test case to test 
the respective outcome for that decision. To assist in building the decision tables, ACT is also 
used to generate annotated listings that indicate the FORTRAN decisions associated with the 
node numbers in the trees and listed in the tables. 

The objective of structural analysis is to ensure that DO-178B's required Modified 
Condition/Decision Coverage (MC/DC) has been met for the Pluto code. As stated in Software 
Verification Cases and Procedures, four conditions must be satisfied to provide coverage. This 
structural analysis has satisfied those four conditions in the following ways: 

1) "Each decision takes on every possible outcome at least once." 

This is satisfied by the primary decision tables for each functional unit and subroutine. 
The primary table contains a TRUE and FALSE column for each decision — a test case 
is given for each. Test cases followed by an indicate that there are multiple 
requirements-based test cases that satisfy the specific decision. Subroutines that do not 
contain any decisions will not have a primary decision table, because any test case that 
enters the routine will exercise all the statements in the routine. Those test cases are 
just listed in the Entry/Exit tables to avoid duplication. 

2) "Each condition in each decision takes on every possible outcome at least once." 

This is demonstrated in the pairs table given for each decision that has multiple 
conditions. Each pairs table has extra columns to the right of the test case column 
showing cases where the condition is tested at each possible out come value. 

3) "Each entry and exit point is invoked at least once." 

This is demonstrated in the Entry/Exit tables for subroutines in each functional unit. 

4) "Each condition is shown to independently effect the decision outcome." 

This is also demonstrated in the pairs table for each decision with multiple conditions. 
The independent impact of each condition on the final decision outcome is shown in 
the independence columns (e.g. "Ind. of con 1") to the right of the test case column. 
The in the column give test cases in which the value of the condition drives the 
outcome of the decision. 


Much of the Pluto code structure was already tested by the requirements coverage test cases. 
Structural test cases are created for only those conditions not covered by the requirements based 
test cases. Since complete path coverage is not an objective in MC/DC requirement, the 
decisions involving a loop counter that is not manipulated or calculated are not tested since any 
test case reaching that point will exercise the loop entirely. These decisions are appropriately 
denoted in the decision tables. 

In the following structural analysis of the Pluto implementation, a section is dedicated for each 
functional unit with the last section for the utility subroutines that are used by all functional unit. 
For each functional unit, a decision tree is first given. The decision tree is generated using the 
ACT software as prescribed in the Verification Cases and Procedures Document. The decision 
tree shows all the branching that occurs in the functional unit and assigns a number for each 
branch. These numbers are used in the decision table to identify the decision being made. The 
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decision tree is followed by one or more tables listing the decision made at the node and the test 
cases that exercise the decision. 


The first table in each section is the primary decision table that lists all decisions occurring in 
the code for the functional unit. Decisions with multiple conditions have a separate pairs table for 
each. Where applicable, Entry/Exit tables are given for subroutines used in a functional unit. 
Decision tables for utility routines specific to each functional unit are placed in the same sections 
as the corresponding functional units. 
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Table B.34: ARSP Decision Table - see Figure B.l for correspondence. 


Graph Node 
Number 

ARSP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

1 

(ARCOUNTER .NE. -1) 

ARSPNRO 1 7 

ARSPNR012* 

4 

((AR STATUS(l) .EQ. K$FAILED) .OR. 
(AR STATUS(2) .EQ. K$F AILED) .OR. 
(AR STATUS(3) .EQ. K$F AILED) .OR. 
(AR STATUS(4) .EQ. K$FAILED)) 

See ARSP MC/DC table 
for decision node 4 


Table B.35: MC/DC Pairs table for decision node 4 of ARSP: 


AR STATUS(l) 

AR STATUS(2) 

AR STATUS(3) 

AR STATUS(4) 

Final 

Test Case 

Ind. 

Ind. 

Ind. 

Ind. 

.EQ. 

.EQ. 

.EQ. 

.EQ. 

Decision 


of 

of 

of 

of 

KSFAILED 

KSFAILED 

KSFAILED 

KSFAILED 







(Con 1) 

(Con 2) 

(Con 3) 

(Con 4) 



Con 1 

Con 2 

Con 3 

Con 4 

0 

0 

0 

0 

0 

ARSPNR01 1 

* 

* 

* 

* 

0 

0 

0 

1 

1 

ARSPNR015 




* 

0 

0 

1 

0 

1 

ARSPNR014 



* 


0 

1 

0 

0 

1 

ARSPNR013 


* 



1 

0 

0 

0 

1 

ARSPNR012 

* 





0 = FALSE value for the condition 

1 = TRUE value for the condition 


No structural test cases were developed for ARSP functional unit. The requirements based 
cases adequately tested the code structure. 
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B.3.5.2 ASP Structural Analysis 

o 
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Table B.36: ASP Decisions Table - see Figure B.2 for correspondence 


Graph 

Node 

Number 

ASP Decisions 

TRUE 
output test 
cases 

FALSE 

output test case 

20 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

22 

((A_STATUS(I,1) .EQ. K$HEALTHY) .AND. 
(A_STATUS(I,2) .EQ. K$HEALTHY) .AND. 
(A_STATUS(I,3) -EQ. K$HEALTHY)) 

See ASP MC/DC pairs table for 
Node 22 

23 

(A ACCELERATIONS) .NE. 
A_ACCELERATION(I,2)) .AND. 
(A ACCELERATION(I,l) .NE. 
A_ACCELERATION(I,3 )) 

See ASP MC/DC pairs table for 
Node 23 

29 

temp .GT. A SCALE * SD 

ASP_NR_002 

ASPPST002 


Table B.37: MC/DC Pairs table for decision node 22 of ASP: 


A STATUS(I,1 
).EQ. 

KSHEALTHY 
(Con. 1) 

A STATUS(I,2 
).EQ. 

KSHEALTHY 
(Con. 2) 

A STATUS(I,3 
) EQ. 

KSHEALTHY 
(Con. 3) 

Final 

Decision 

Test Case 

Ind. 

of 

Coni 

Ind. 

of 

Con 2 

Ind. 

of 

Con 3 

1 

1 

0 

0 

ASP NR 005 



* 

1 

0 

1 

0 

ASP_NR_004 


* 


0 

1 

1 

0 

ASP NR 003 

* 



1 

1 

1 

1 

ASP NR 001 

* 

* 

* 


0 = FALSE value for the condition 

1 = TRUE value for the condition 


Table B.38: MC/DC Pairs table for decision node 23 of ASP: 


(A ACCELERATION(I,l 
) 

.NE. 

A ACCELERATION^) 
) 

(Con. 1) 

(A ACCELERATION (1,1 
) 

.NE. 

A ACCELERATION (1,3 ) 
) 

(Con. 2) 

Final 

Decision 

Test Case 

Ind. 

of 

Con 1 

Ind. 

of 

Con 2 

0 

0 

0 

ASP PST_001 

* 

* 

0 

1 

1 

ASP PSTJXB 


* 

1 

0 

1 

ASP_PST_004 

* 



0 = FALSE value for the condition 

1 = TRUE value for the condition 
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B.3.5.3 ASP Structural Testing 


Code components tested in ASP structural testing are in Table B.4. Recall from the 
Verification Cases & Procedures document that structural-based test are setup and executed in the 
same manner as requirements-based functional unit tests. Hence the code components tested in 
structural-based testing are also identical. Table B.39 gives the summary log of ASP structural 
testing. There are 4 structural test cases for ASP. 


Table B.39: Summary of Structural Testing for ASP Functional Unit 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA flle/PR # 

Reason for Test Run 

ASPPSTxxx 

4/11/95 

N 

Initial testing 
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Table B.40: GSP Decision Table — see Figure B.3 for correspondence. 


Graph 

Node 

Number 

GSP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

2 

I in range (loop based on I) 

Not a calculated loop counter; Testing not required 

5 

BTEST(G_COUNTER(I), 15) .EQ. .TRUE. 

GSPNR001 

GSPNR 004* 


No structural test cases were developed for GSP functional unit. The requirements based 
cases adequately tested the code structure. 
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Table B.41: TSP Decision Table — see TSP graph for correspondence. 


Graph 

Node 

Number 

TSP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

4 

(SOLID STATE TEMP .LT. 

LOWER PARABOLIC_TEMP LIMIT) .OR. 

(SOLID STATE TEMP .GT. 

UPPER PARABOLIC TEMP LIMIT) 

TSPNR 002* 

TSPNR00 1 * 

6 

THERMO_TEMP .LT. M3 

TSP NR 006 

TSPNR001 

9 

THERMO TEMP .GT. M4 

TSP NR 007 

TSP NR 001 


Table B.42: MC/DC Pairs table for decision node 4 of TSP: 


SOLID STATE 

TEMP 

SOLID STATE_TEMP 

Final 

Test Case 


bid. 

.LT. 


.GT. 

Decision 


of 

of 

LOWER PARABOLIC 
T 

(Con 1) 

TEMPLIMI 

UPPER PARABOLIC_TEMP LIMIT 
(Con 2) 



Coni 

Con 2 

0 

0 

0 

TSP NR 001* 

* 

* 

0 

1 

1 

TSP NR 003 


* 

1 

0 

1 

TSP NR 002 

* 



0 = FALSE value for the condition 

1 = TRUE value for the condition 


Table B.43: MC/DC Entry/Exit requirements — for Modules inside TSP.FOR: 


Module 

Test Case 

LOWER PARABOLIC FUNCTION 

TSP NR 001* 

UPPER PARABOLIC FUNCTION 

TSP NR 001* 


No structural test cases were developed for TSP functional unit. The requirements based cases 
adequately tested the code structure. 
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Table B.44: TDSP Decisions — see Figure B.5 for correspondence. 


Graph Node 
Number 

TDSP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

1 

TDS STATUS .EQ. K$HEALTHY 

TDSP NR 001* 

TDSP NR 004 

2 

TD COUNTER .EQ. 0 

TDSP NR 001 

TDSP NR 002 

4 

TD COUNTER .EQ. -1 

TDSP NR 002 

TDSP NR 003 


No structural test cases were developed for TDSP functional unit. The requirements based 
cases adequately tested the code structure. 


B-36 




















Table B.45: TDLRSP Decisions — see TDLRSP graph for correspondence. 


Graph Node 
Number 

TDLRSP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

1 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

2 

TDLR COUNTER* I) .EQ. 0 

TDLRSP NR 003* 

TDLRSP NR 001* 

3 

TDLR STATE(I) .EQ. K$BEAM LOCKED 

TDLRSP NR 005 

TDLRSP NR 003 

5 

TDLR STATE(I) .EQ. K$BEAM UNLOCKED 

TDLRSP NR 003 

TDLRSP RO 026 

7 

ELAPSED TIME .GE. TDLR LOCK TIME 

TDLRSP NR 003 

TDLRSP RO 004 

12 

TDLR STATE(I) .EQ. KSBEAM UNLOCKED 

TDLRSP NR 001 

TDLRSP RO 006 

14 

ELAPSED TIME .GE. TDLR LOCK TIME 

TDLRSP NR 021 

TDLRSP RO 002 

21 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

25 

This is a CASE statement implemented in VMS 
FORTRAN as a computed GOTO 

See Table on Decision 25 


Table B.46: Expanded table for Decision 25. 


TDLRSTATE(l) + 
2*TDLR_STATE(2) + 
4*TDLR_STATE(3) + 
8*TDLR STATE(4) + 1 

Test 

Case 

1 

TDLRSP NR 005 

2 

TDLRSP NR 007 

3 

TDLRSP NR 008 

4 

TDLRSP NR Oil 

5 

TDLRSP NR 009 

6 

TDLRSP NR 012 

7 

TDLRSP NR 014 

8 

TDLRSP NR 017 

9 

TDLRSP NR 010 

10 

TDLRSP NR 013 

11 

TDLRSP NR 015 

12 

TDLRSP NR 018 

13 

TDLRSP NR 016 

14 

TDLRSP NR 019 

15 

TDLRSP NR 020 

16 

TDLRSP NR 021 

Out of range 

TDLRSP RO 026 


No structural test cases were developed for TDLRSP functional unit. The requirements based 
cases adequately tested the code structure. 
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Table B.47: CP Decisions — see CP graph for correspondence. 


Graph 

Node 

Number 

CP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

2 

SUBFRAME COUNTER .EQ. 1 

CP NR 001 

CP NR 002* 

5 

SUBFRAME COUNTER .EQ. 2 

CP NR 002 

CP NR 003 


Table B.48: CRC16 Decision. 


Module 

Test Case 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required. 


Table B.49: MC/DC Entry /Exit requirements for Module inside CP.FOR: 


Module 

Test Case 

CRC16 

CP NR 001* 


No structural test cases were developed for CP functional unit. The requirements based cases 
adequately tested the code structure. 
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B.3.5.9 GP Structural Analysis 



Figure B.9: GP Decision Tree: 
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Table B.50: GP Decisions — see Figure B.9 for correspondence. 


Graph 

Node 

Number 

GP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

63 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

64 

J in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

72 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

79 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

80 

J in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

86 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

92 

AESWITCH .EQ. KSAXIALENGINESAREOFF 

GPNR001* 

GP NR 003* 

93 

RE SWITCH .EQ. KSROLL ENGINES ARE ON 

GP NR 001* 

GP NR 105* 

94 

TDSENSED .EQ. KSTOUCHDOWNNOTSENSED 

GP NR 001* 

GP PST 001 

95 

GP ALTITUDE(O) .LE. ENGINESONALTITUDE 

GP PST 003 

GP PST 002 

100 

TD SENSED .EQ. KSTOUCHDOWNSENSED 

GP NR 003* 

GPNR102* 

102 

GP ALTITUDE(O) .LE. DROP HEIGHT 

GPNR 007* 

GP NR 003* 

106 

SQRT(TEMP)+GP_VELOCITY( 1,0) .LE. MAX NORMAL VELOCITY 

GP PST 004 

GPNR007 

112 

I in range (loop based on I) 

Not a calculated loop counter; 
Testing not required 

113 

CONTOURALTITUDE(I) .EQ. CUR ALTITUDE 

GP PST 006 

GP PST 005 

116 

CONTOUR ALTITUDE(I) .GT. CUR ALTITUDE 

GP PST 005 

GP PST 007 

117 

I .GT. 1 

GP PST 005 

GP PST 008 

123 

(CONTOUR ALTITUDE(I) .EQ. 0) .OR. (I .EQ. 100) 

See MC/DC table for decision 123 j 

132 

GPALTITUDE(O) .LE. ENGINE SONALTITUDE 

GP PST 009 

GP PST 010 

133 

CONTOUR CROSSED .EQ. KSCONTOUR NOT CROSSED 

GP PST 012 

GP PST 009 

134 

VELOCITY ERROR .GE. 0 

GP PST 012 

GP PST 011 

139-145 

GOTO statement based on GPPHASE 

See Table based on GP PHASE Decision | 

147 

GP ALTITUDE(O) .LE. ENGINES ON ALTITUDE 

GP NR 001* 

GP RO 107 

151 

TD SENSED .EQ. KSTOUCH DOWN SENSED 

GPNR102 

GPNR 002* 

153 

AETEMP .EQ. KSHOT 

GPNR004 

GPNR003 

154 

CHUTE RELEASED .EQ. KSCHUTERELEASED 

GPNR004 

GP RO 110 

160 

TD SENSED .EQ. KSTOUCH DOWN SENSED 

GPNR104 

GP NR 005* 

162 

GP ALTITUDE(O) .LE. DROP HEIGHT 

GPNR 007* 

GP NR 008 

163 

TDSSTATUS .EQ. KSFAILED 

GPNR006 

GPNR008 

168 

SQRT(TEMP)+GP VELOCITY) 1,0) .LE. 
MAX NORMAL VELOCITY 

GPNR008 

GPNR007 

175 

TD SENSED .EQ. KSTOUCH DOWN SENSED 

GPNR105 

GP PST 013 

177 

TDS STATUS .EQ. KSFAILED 

GP PST 014 

GP PST 013 

182 

CL .EQ. KSFIRST 

GP NR 001* 

GPNR 007* 

183 

OPTIMAL VELOCITY .EQ. DROP SPEED 

GP PST 015 

GP PST 019 

184 

GP VELOCITY! 1, 0) ,LT. DROP SPEED 

GP PST 016 

GP PST 015 


is used in the above table to indicate that there are more test cases that satisfy this decision branch but only one is listed for 
brevity. 
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Table B.51: MC/DC table for Decision 123. 


CONTOUR ALTITUDE(I) .EQ. 0 

(Con. 1) 

(I .EQ. 100) 

(Con. 2) 

Final 

Decision 

Test Case 

Ind. of 

Coni 

Ind. of 

Con 2 

0 

0 

0 

GP PST 007 a 

* 

* 

0 

1 

1 

GP PST 007 a 


* 

1 

0 

1 

GPPST017 

* 



0 = FALSE value for the condition 

1 = TRUE value for the condition 

A: Test case GP PST007 iterates through decision-123 100 times. The first 99 iterations will exercise the 0,0 
combination while the 100th iteration will exercise the 0,1 combination of the decision. 

Table B.52: Expanded table for GPPHASE Decision. 


GP_PHASE 

Test Case 

1 

GPNR001* 

2 

GPNR 002* 

3 

GPNR 005* 

4 

GPNR105 

5 

GPPST010 

Out of range 

GPPST020 


Table B.53: MC/DC Entry/Exit requirements for Module inside GP.FOR: 


Module 

Test Case 

DERIVATT 

GPNR001* 

DERIVVEL 

GPNR001* 

DERIVALT 

GPNR001* 

MULTATT 

GPNR001* 

MULTVEL 

GPNR001* 

AVGATT 

GPNR001* 

AVGVEL 

GPNR001* 


3.5.10 GP Structural Testing 

Code components tested for GP structural -based testing are identified in Table B.14. There 
are 21 test structure-based test cases. Only 20 are used to test GP code stricture. GPPST018 is 
not used for GP structural analysis because it test the same condition as GPPST 007. It should 
also be noted that GPPST021 is used to test the ZEROCHECK routine in the UTILITY.FOR 
file. This test case forces a negative-square -root to occur in the GP functional unit and is 
expected to cause a core dump. Hence even though an expected-values file is provided, it is not 
needed. 
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Table B.54: Summary of Structural Testing for GP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

RESULTS 
.ANA file/PR # 

Reason for Test Run 

GPPSTxxx 

4/11/95 

N 

Initial testing. 
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Table B.55: AECLP Decisions — see Figure B.10 for correspondence 


Graph 

Node 

Number 

AECLP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

1 

AESWITCH .EQ. K$AXIAL_ENGINES_ARE_OFF 

AECLPNR 008* 

AECLPNR00 1 * 

4 

GPALTITUDE(O) .LE. ENGINESONALTITUDE 

AECLP NR 001* 

AECLP RO 044* 

5 

AETEMP .EQ. K$COLD 

AECLPNROO 1 * 

AECLP NR 003* 

6 

(FRAME COUNTER - FRAME ENGINES IGNITED) * DELTA T 
.LT. 

FULL UP TIME 

AECLP NR 00 1 * 

AECLP_RO_4 1 * 

9 

AE TEMP .EQ. K$WARMING_UP 

AECLPNR003 * 

AECLPNR 005 * 

10 

(FRAME COUNTER - FRAME ENGINES IGNITED) * DELTA T 
.GE. 

FULL UP TIME 

AECLPNR003 * 

AECLP RO 043* 

24 

PITCH ERROR LIMIT .LT. PE MIN(CL) 

AECLPRO027 

AECLPNR00 1 * 

26 

PITCH ERROR LIMIT .GT. PEMAX(CL) 

AECLP RO 028 

AECLP NR 001* 

37 

YAWERRORLIMIT .LT. YEMIN(CL) 

AECLPRO035 

AECLPNROO 1 * 

39 

YAWERRORLIMIT .GT. YE MAX(CL) 

AECLPRO036 

AECLPNR00 1 * 

43 

CONTOUR CROSSED .EQ. KSCONTOUR CROSSED 

AECLP RO 005* 

AECLPNROO 1 * 

50 

OMEGA .NE. 0 

AECLP RO 005* 

AECLP PST 001 

55 

TELIMIT .LT. TEMIN(CL) 

AECLP RO 029 

AECLPNROO 1 * 

57 

TE LIMIT .GT. TE MAX(CL) 

AECLP R0 030 

AECLPNROO 1 * 

62 

CHUTE RELEASED .EQ. KSCHUTERELEASED 

AECLPNR 004* 

AECLPNROO 1 * 

63 

CONTOUR CROSSED .EQ. KSCONTOUR NOT CROSSED 

AECLPNR004 

AECLPNR005 

72 

I IN RANGE 

Not a calculated loop counter; 
Testing not required 

73 

INTERN AL_CMD(I) .LT. 0 

AECLPNR054 

AECLPNROO 1 * 

75 

INTERN AL_CMD(I) .LE. 1 

AECLPNR00 1 * 

AECLPNR055 


B.3.5.12 AECLP Structural Testing 

Code components tested in AECLP structural testing are given in Table B.14. The results of 
structural testing is given in Table B.56. There are only two test cases in this suite. 
AECLPPSTOO 1 tests a decision in the AECLP functional unit. AECLP_PST_002 is designed 
to test the ZERO CHECK subroutine in the UTILITY.FOR file. It forces a divide-by-zero to 
occur and is expected to cause a core dump. An expected values file is provided for this test case 
but is unnecessary. The objective of the test is to ensure that the exception message is displayed 
or printed. Hence this test case is not expected to run to completion. 


Table B.56: Summary of Structural Testing for AECLP Functional Unit. 


TEST CASE 

EXECUTION 

RESULTS 

Reason for Test Run 

NAME 

DATE 

.ANA file/PR # 


AECLPPSTOO 1 

4/11/95 

N 

Initial testing 

AECLPPST002 


N 

Initial testing 
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Table B.57: RECLP Decisions — see Figure B.l 1 for correspondence 


Graph Node 
Number 

RECLP Decisions 

TRUE 

output test cases 

FALSE 

output test case 

1 

RE SWITCH .EQ. 
K$ROLL ENGINES ARE OFF 

RECLPPST003 

RECLP NR 001* 

6 

THETA .EQ. 0 

RECLPNR 059 

RECLP NR 001* 

7 

G_ROTATION( 1 , 0) .GT. P4 

RECLP NR 064 

RECLP NR 065 

9 

G_ROTATION(l, 0) ,LT. -P4 

RECLPPST 0 1 1 

RECLP NR 065 

14 

THETA .GT. 0 

RECLP NR 001* 

RECLP NR 066* 

l 15 

THETA .LE. THETA 1 

RECLP NR 001* 

RECLP NR 005 

i 16 

G_ROTATION(l, 0) .GT. P2 

RECLP NR_0 13* 

RECLP NR 001* 

18 

G ROTATION!!, 0) .GT. PI 

RECLP PST 001 

RECLP NR 001* 

20 

G_ROTATION( 1 , 0) .GE. -P4 

RECLP NR 001 

RECLP PST 002 

26 

THETA .LE. THETA2 

RECLP NR 005* 

RECLP NR 009 

27 

G_ROTATION(l, 0) .GT. P2 

RECLP PST 004 

RECLP NR 005* 

29 

G ROTATION! 1, 0) .GT. PI 

RECLP NR 021 

RECLP NR 005* 

31 

G_ROTATION(l, 0) .GT. 0.0 

RECLP NR 008 

RECLP NR 005* 

33 

G ROTATION! 1, 0) .GE. -P4 

RECLP NR 005 

RECLP NR 043 

40 

G_ROTATION(l, 0) .GT. -P3 

RECLPNR012* 

RECLP NR 039 

42 

G_ROTATION(l, 0) .GE. -P4 

RECLP NR 039 

RECLP PST 005 

49 

THETA .GE. -THETA 1 

RECLP NR 002 

RECLP NR 063 

50 

G ROTATION! 1, 0) .GT. P4 

RECLP PST 006 

RECLP NR 002* 

52 

G_ROTATION( 1 , 0) .GE. -PI 

RECLP NR 002 

RECLP PST 007 

54 

G ROTATION! 1, 0) .GE. -P2 

RECLP PST 007 

RECLP PST 008 

60 

THETA .GE. -THETA2 

RECLP NR 006 

RECLP NR 010 

61 

G ROTATION! 1, 0) .GT. P4 

RECLP PST 009 

RECLP NR 006 

63 

G_ROTATION(l, 0) .GE. 0.0 

RECLPNR007 

RECLP NR 006 j 

65 

G_ROTATION(l, 0) .GE. -PI 

RECLP NR 006 

RECLP NR 023 i 

67 

G_ROTATION( 1 , 0) .GE. -P2 

RECLP NR 023 

RECLP PST 010 

74 

G_ROTATION(l, 0) .GT. P4 

RECLP RO 063 

RECLP NR 010 

76 

G_ROTATION(l, 0) .GE. P3 

RECLP NR 010 

RECLP NR 01 1 


B.3.5.14 RECLP Structural Testing 

Table B.l 8 gives the code components tested by RECLP structural testing. The results are 
summarized in Table B.58 below. There are 1 1 test structure-based test cases in this suite. 


Table B.58: Summary of Structural Testing for RECLP Functional Unit. 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE CODE 
FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

RECLPPSTxxx 

4/11/95 

4/6/95 

4/10/95 

N 
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Table B.59: CRCP Decisions — see Figure B.12 for correspondence 


Graph 

Node 

Number 

CRCP Decisions 

TRUE 

output test cases 

FALSE 

output test ease 

1 

CHUTE RELEASED .EQ. 
K$CHUTE_ATT ACHED 

CRCPNROO 1 * 

CRCPNR002 * 

2 

AE TEMP .EQ. K$HOT 

CRCPNR005 

CRCPNROO 1 * 


No structure-based test cases are needed for CRCP. 


B.3.5.16 Utility Subroutines Structural Analysis 

Utility routines are used throughout the various functional units for range checking, as well as 
checking for negative and zero numbers. These test cases are executed along with the functional 
units. 


Table B.60: RANGE CHECK Subroutine Decisions: 


Graph Node 
Number 

RANGECHECK Decisions 

TRUE 

output test cases 

FALSE 

output test case 


source .LT. lower bound 

GSPRO 002* 

ASP_NR_00 1 * 


source .GT. upper_bound 

GPRO003 

ASP_NR_00 1 * 


Table B. 61: NEG VALUE CHECK Subroutine Decisions: 


Graph Node 
Number 

NEGVALUECHECK Decisions 

TRUE 

output test cases 

FALSE 

output test case 


source .LT. 0 

GPPST021 

GPNR007 


Table B.62: ZERO CHECK Subroutine Decisions: 


Graph Node 
Number 

ZEROCHECK Decisions 

TRUE 

output test cases 

FALSE 

output test case 


source .EQ. 0 

AECLPPST002 

AECLPNR001 
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B.4 Traceability Matrix for Pluto Design and Code 


This section gives the traceability matrix to match Pluto design and code elements to the GCS 
requirements. 


Table B.4-1: Pluto Traceability Matrix 


Functional Requirements 

DESIGN 

CODE 

0-1 Specify four separate, globally accessible 
data stores: 

EXTERNAL, 

GUIDANCE STATE, 

RUN PARAMETERS, and 
SENSOROUTPUT. 

DFD 1 
DFD 2 
DFD 3 

Guidancestate.for 
RunParameters.for 
Sensoroutput.for 
External, for 

2-1 Control flow of the frame processing. 



2-1.1 The appropriate control flow for a frame is: 

call to GCSSIMRENDEZVOUS. 

Satisfy the Sensor Processing subframe requirements (2-2). 
call to GCS SIM RENDEZVOUS. 

Satisfy Guidance Processing subframe requirements (2-3). 
call to GCS SIM REN DEZ V OUS 

fulfill Control Law Processing subframe requirements (2-4) or 
terminate (2-1.2). 

PAT 0-sl 
PAT 1-sl 
PAT 2-sl 
PAT 3 -si 

Program Pluto 
Subroutine SPSF 
Subroutine GPSF 
Subroutine CLPSF 

2-1.2 The implementation is to terminate immediately upon completion of the 

Control Law Processing subframe requirements during the frame in which GP PHASE is 
set to 5. 

DFD 2 
P Spec. 2.2 
PAT 0-sl 

Program Pluto 

2-2 Sensor Processing subframe requirements. 



2-2. 1 Satisfy the TSP requirements (2. 1 .5) prior to fulfilling any of the other 

requirements in (2. 1 . 1 and 2.1.4). 

PAT 1-sl 

Subroutine SPSF 

2-2.2 Satisfy all requirements in the sensor processing requirements hierarchy (2.1). 

PAT 1-sl 

Subroutine SPSF 

2-2.3 Satisfy all requirements in the communications processing requirements 

(2.4) upon satisfying 2-2.1. 

PAT 1-sl 
P Spec. 1.8 

Subroutine SPSF 
Subroutine CP 

2-2.4 Adhere to the functional unit scheduling in Table 4.3 of the GCS 

specification. 

PAT 0-sl 

Subroutine SPSF 

2-3 The Guidance Processing subframe requirements. 



2-3.1 Satisfy all requirements in the guidance processing requirements 

(2.2). 

PAT 2-sl 

Subroutine GPSF 

2-3.2 Satisfy all requirements in the communications processing requirements 

(2.4) upon satisfying 2-3.1. 

PAT 2-sl 
P Spec. 2.3 

Subroutine GPSF 
Subroutine CP 

2-4 The Control Law Processing subframe requirements. 



2-4. 1 Satisfy the AECLP requirements (2.3.1) prior to fulfilling any of the 

CRCP requirements (2.3.3). 

PAT 3 -si 

Subroutine CLPSF 
Subroutine AECLP 

2-4.2 Satisfy all requirements in the control law processing requirements 

hierarchy (2.3). 

PAT 3 -si 

Subroutine CLPSF 

2-4.3 Satisfy all requirements in the communications processing requirements 

(2.4) upon satisfying 2-4.1. 

PAT 3 -si 
P Spec. 3.5 

Subroutine CLPSF 
Subroutine CP 

2-4.4 Adhere to the functional unit scheduling in Table 4.3 of the GCS 

specification. 

PAT 3 -si 

Subroutine CLPSF 

2.1 SP -- Sensor Processing 



2.1.1 ASP -- Accelerometer Sensor Processing 



2. 1 . 1 - 1 Rotate variables. 

P_Spec 1.3 (step 1) 

Subroutine ASP 

2. 1 . 1 -2 Adjust gain for temperature. 

PSpec 1.3 (step 3) 

Subroutine ASP 

2 . 1 . 1 -3 Remove characteristic bias . 

PSpec 1.3 (step 3) 

Subroutine ASP 

2 . 1 . 1 -4 Correct for misalignment. 

P Spec 1.3 (step 3) 

Subroutine ASP 

2. 1 . 1 -5 Determine Accelerations. 



2 . 1 . 1 -5 . 1 Acceleration based on current A COUNTER. 

P Spec 1.3 (step 3) 

Subroutine ASP 

2. 1.1 -5.2 Acceleration based on mean of previous accelerations. 

P Spec 1.3 (step 3) 

Subroutine ASP 

2 . 1 . 1 -6 Determine Accelerometer Status 



2. 1.1 -6.1 A STATUS = healthy 

P Spec 1.3 (step 2) 

Subroutine ASP 

2.1.1 -6.2 ASTATUS = unhealthy 

P_Spec 1.3 (step 2) 

Subroutine ASP 

2.1.2 ARSP -- Altimeter Radar Sensor Processing 



2. 1.2-1 Rotate variables. 

P Spec 1 .2 (step 1 ) 

Subroutine ARSP 

2. 1.2-2 Determine altitude when echo is received, (based on AR COUNTER) 

P Spec 1 .2 (step 3 A) 

Subroutine ARSP 

2.1 .2-3 Determine altitude when echo is not received 



2.1. 2-3.1 Determine altitude based on third-order polynomial. 

P Spec 1.2 (step 2B) 

Subroutine ARSP 

2.1 .2-3 .2 Determine altitude based on previous calculation. 

P_Spec 1 .2 (step 2C) 

Subroutine ARSP 



























































































2. 1 .2-4 Set altimeter radar status. 


2. 1 .2-4. 1 ARSTATUS = healthy 


2.1. 2-4.2 AR STATUS = failed 


2. 1 .2-5 Set values of K ALT. 


2.1. 2-5.1 K ALT = 1 


2. 1.2-5 .2 K ALT = 0 


TDLRSP -- Touch Down Landing Radar Sensor 


2. 1.3-1 Rotate variables 


2. 1 .3-2 Determine state for each radar beam. 


2.1. 3-2.1 TDLR STATE = unlocked. 


2.1. 3-2.2 TDLR STATE = locked. 


2. 1.3-3 Determine Whether to set FRAME BEAM UNLOCKED 


2.1. 3-3.1 Set FRAME BEAM UNLOCKED to FRAME COUNTER 


2. 1 .3-3.2 Leave F RAME BE AM UN LOCKED unchanged 


2. 1 .3-4 Calculate the beam velocities 


2. 1 .3-5 Process beam velocities based on which beam(s) locked. 


2.1. 3-5.1 no beams locked 


2. 1.3-5 .2 Beaml locked 


2.1. 3-5.3 Beam2 locked 


2. 1.3-5 .4 Beam3 locked 


2. 1.3-5. 5 Beam4 locked 


2.1. 3-5.6 Beaml & Beam2 locked 


2.1. 3-5.7 Beaml & Beam3 locked 


2. 1.3-5. 8 Beaml & Beam4 locked 


2.1. 3-5.9 Beam2 & Beam3 locked 


2.1.3-5.10 Beam2 & Beam4 locked 


2.1.3-5.11 Beam3 & Beam4 locked 


2.1.3-5.12 Beaml, Beam2, & Beam3 locked 


2.1.3-5.13 Beaml, Beam2, & Beam4 locked 


2.1.3-5.14 Beaml, Beam3, & Beam4 locked 


2.1.3-5.15 Beam2, Beam3, & Beam4 locked 


2.1.3-5.16 Beaml, Beam2, Beam3, & Beam4 locked 


2. 1 .3-6 Convert to body velocities. 


2. 1 .3-7 Set values in K MATRIX. 


2. 1.3-7. 1 Kx = 0 


2.1. 3-7.2 Kx=l 


2.1. 3-7.3 Ky = 0 


2.1 .3-7.4 Ky = 1 


2.1. 3-7.5 Kz = 0 


2.1. 3-7.6 Kz = 1 


2. 1.3-8 Set TDLR STATUS. 


GSP -- Gyroscope Sensor Processing 


P_Spec 1 .2 (step 2) 


P Spec 1 .2 (step 2) 


PSpec 1.2 (step 2) 


P Spec 1 .2 (step 2) 


TSP — Temperature Sensor Processing 


2. 1 .5- 1 Calculate solid state temperature 


2. 1 .5-2 Calculate Thermal Temperature 


2. 1 .5-3 Determine which Temperature to use (SS or Thermocouple) 


2. 1 .5-3 . 1 Calculate the Thermo sensor upper limit 


2. 1 .5-3.2 Calculate the Thermo sensor lower limit 


Determine Atmospheric Temperature 


Set status to healthy. 


TDSP -- Touch Down Sensor Processing 


Determine status of touch down sensor. 


Determine whether touch down has been sensed. 


GP -- Guidance Processing 


Rotate variables. 


Determine the attitude, velocities, and altitude. 


Set up the GP ROTATION matrix. 


P Spec 1 .5 (step 3 A) 


P Spec 1 .5 (step 3 A) 


P Spec 1.5 (step 3 A) 


P Spec 1 .5 (step 3 A) 


P Spec 1.5 (step 3B) 


PSpec 1 


PSpec 1 


P Spec 1 


PSpec 1 


PSpec 1 


P Spec 1 


PSpec 1 


PSpec 1 


P Spec 1 


PSpec 1 


PSpec 1 


P Spec 1 


PSpec 1 


PSpec 1 


P Spec 1 


PSpec 1 


PSpec 1 


2. 1.4-1 

Rotate variables. 


2. 1.4-2 
axes. 

Determine the vehicle rotation rates along each of the 

vehicle's three 

2.1. 4-2.1 

Adjust gain. 


2.1. 4-2.2 

Convert G COUNTER. 


2. 1.4-3 

Set gyroscope status to healthy. 



.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3C) 


.5 (step 3D) 


P Spec 1.5 (step 4) 


P Spec 1.5 (step 4) 


P Spec 1.5 (step 4) 


P Spec 1.5 (step 4) 


P Spec 1.5 (step 4) 


P Spec 1.5 (step 4) 


P Spec 1.5 (step 2) 


P Spec 1 .4 (step 3) 


P Spec 1 .4 (step 3) 


P Spec 1 .4 (step 2) 


P_Spec 1 .7 (step 2 A) 


P Spec 1 .7 (step 2C) 


P Spec 1 .7 (step 2B) 


P Spec 1 .7 (step 2B) 


PSpec 1.7 
(step 2B & 2C) 


P Spec 1.7 (step 1) 


P Spec 1.6 (step 1) 


P Spec 1.6 (step 2) 


P_Spec 2.2 (step 1) 


P Spec 2.2 (step 2) 


Subroutine ARSP 


Subroutine ARSP 


Subroutine ARSP 


Subroutine ARSP 



Subroutine TDLRSP 


Subroutine TDLRSP 


Subroutine TDLRSP 


Subroutine TDLRSP 


Subroutine TDLRSP 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


Subroutine 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 



Subroutine TDLRSP 


Subroutine TDLRSP 


Subroutine TDLRSP 


Subroutine TSP 


Subroutine TSP 


Function 

UPPERPARABOLIC 

FUNCTION 


Function 

LOWERPARABOLIC 

FUNCTION 


Subroutine TSP 


Subroutine TSP 


Subroutine TDSP 


Subroutine TDSP 


Subroutine GP 


Subroutine 
DERIV ATT 
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PSpec 2.2 (step 2) 



Determine if the engines should be on or off. 


Engines on 


Engines off 


Set FRAME ENGINES IGNITED 


Determine velocity error. 


Determine optimal velocity 


Determine if contour has been crossed. 


Determine guidance phase. 


GP PHASE = 1 


GP PHASE = 2 


GP PHASE = 3 


GP PHASE = 4 


GP PHASE = 5 


Determine which set of control law parameters to use. 


CL = 1 


CL = 2 


CLP — Control Law Processing 


AECLP -- Axial Engine Control Law Processing 


2.3.3 CRCP -- Chute Release Control Processin 


2.3.3-1 Determine appropriate parachute release command. 


2. 3.3-1. 1 AE TEMP = COLD 


2.3.3-1.2 AE TEMP = WARM 


2.3.3-1.3 AE TEMP = HOT 


2.3.3-1.4 CHUTE RELEASED = 0 


2. 3.3-1. 5 CHUTE RELEASED = 1 


2.4 CP — Communications Processing 


2.4-1 Set communicator status to healthy. 


-2 Get synchronization pattern. 


-3 Determine sequence number. 


2.4-4 Prepare sample mask. 


2.4-4. 1 Subframe 1 mask 


2.4-4.2 Subframe 2 mask 


2.4-4.3 Subframe 3 mask 


-5 Prepare data section. 


2.4-5. 1 Use subframe 1 data 


.2 Use subframe 2 data 


Use subframe 3 data 


Calculate checksum. 


P Spec 2.2 (step 3) 


P Spec 2.2 (step 3) 


P Spec 2.2 (step 3) 


P_Spec 2.2 (step 4) 


P Spec 2.2 (step 4) 


P Spec 2.2 (step 5) 


P Spec 2.2 (step 6) 


P Spec 2.2 (step 6) 


P Spec 2.2 (step 6) 


P Spec 2.2 (step 6) 


P Spec 2.2 (step 6) 


P Spec 2.2 (step 7) 


P Spec 2.2 (step 7) 


2.3. 1-1 

Generate the appropriate axial engine commands when 

AE_CMD=ON. 

2.3. 1-1.1 

Determine engine temperature 


2.3. 1-1. 1.1 

AETEMP = COLD 


2.3. 1-1. 1.2 

AE TEMP = WARM 


2.3. 1-1. 1.3 

AE TEMP = HOT 


2.3. 1-1.2 

Compute limiting errors for pitch 


2.3. 1-1.3 

Compute limiting error for yaw 


2.3. 1-1.4 

Compute limiting error for thrust 


2.3. 1-1.5 

Compute pitch, yaw, and thrust errors. 


2.3. 1-1.5. 1 

CHUTE RELEASED = 1 


2. 3. 1-1. 5.2 

CHUTE RELEASED = 0 


2. 3. 1-1.5. 3 

CONTOURCROSSED = 1 


2. 3. 1-1. 5.4 

CONTOUR CROSSED = 0 


2.3. 1-1.6 

Compute INTERN ALCMD 


2.3. 1-1.7 

Compute axial engine valve settings (AE CMD). 


2. 3. 1-1.7. 1 

when INTERN ALCMD < 0.0 


2.3.1 - 1 .7.2 

when 0.0 £ INTERN ALCMD > 1.0 


2. 3. 1-1.7. 3 

when 1.0 < INTERNAL CMD 


2.3. 1-2 

Generate the appropriate axial engine commands when 

AE_CMD=OFF. 

2.3. 1-2.1 

SetAE CMD = 0 


2.3. 1-3 

Set axial engine status to healthy. 


2.3.2 

RECLP -- Roll Engine Control Law Processing 


2.3.2-1 

Generate the appropriate roll engine command. 


2.3.2-2 

Set roll engine status to healthy. 



P_Spec 3.2 (step 2 A) 


P Spec 3.2 (step 2 A) 


P Spec 3.2 (step 2 A) 


P Spec 3.2 (step 2B) 


P Spec 3.2 (step 2C) 


P Spec 3.2 (step 2D) 


P Spec 3.2 (step 2E) 


P Spec 3.2 (step 2E) 


P Spec 3.2 (step 2E) 


P Spec 3.2 (step 2E) 


P Spec 3.2 (step 2F) 


PSpec 3.2 
(step 2G) 


P_Spec 3.2 
(step 2G) 


PSpec 3.2 
(step 2G) 


P Spec 3.2 (step 2) 


P Spec 3.2 (step 1) 


P Spec 3.4 (step 2) 


P Spec 3.4 (step 1) 


P Spec 3.3 


P Spec 3.3 


P Spec 3.3 


P Spec 3.3 


P Spec 3.3 


P Spec 1.8 (step 1) 


P Spec 1.8 (step 2A) 


P Spec 1.8 (step 2B) 


P Spec 1.8 (step 2C) 


P Spec 1.8 (step 2C) 


P Spec 1.8 (step 2C) 


P Spec 1.8 (step 2D) 


P Spec 1.8 (step 2D) 


P Spec 1.8 (step 2D) 


P Spec 1.8 (step 2E) 


Subroutine: 

GP 

DERIVATT 
DER1VVEL 
DERIVATT 
MULTATT 
MULTVEL 
MULT ATT 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 


Subroutine GP 



Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine AECLP 


Subroutine RECLP 


Subroutine RECLP 


Subroutine CRCP 


Subroutine CRCP 


Subroutine CRCP 


Subroutine CRCP 


Subroutine CRCP 


Subroutine CP 


Subroutine CP 


Subroutine CP 


Subroutine CP 


Subroutine CP 


Subroutine CP 


Subroutine CP 


Subroutine CP 


Subroutine CP 


Function CRC16 
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Appendix C: Review Records for the Pluto Implementation of the 
Guidance and Control Software 


Author: Kelly J. Hayhurst, NASA Langley Research Center 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 
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C.l Pluto Preliminary Design Review 


Attendees: Kelly Hayhurst (SQA representative/Moderator) 

Rob Angellatta (Verification Analyst/Recorder, Inspector) 

Paul Carter (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/Inspector) 

C.1.1 Review Notes from Preliminary Design Review 
Session 1: 9/16/93 9:30 a.m. - 11:30 p.m. 

Reviewed Design Review procedures and roles prior to starting review 

High-Level Structured Analysis Diagrams 
Context diagram 

B - 1 — Initialization Data not used exactly as in spec; also mix of control and data flow 

INITRUNGCS does not show AESWITCH and RE SWITCH as outputs (should) 

B - 50 - FRAME COUNTER and SUBFRAMECOUNTER not shown as input from 
GCSSIM 

1N1T RUN GCS 

B-78, R-4 — INIT GCS — no need for design to redo initialization 

B-16 — problems with data stores RUN PARAMETERS, GUIDANCE STATE, and 
SENSOROUTPUT 

B-52 — complete set of flows into and out of EXTERNAL are missing 
problem with the external data flow — not consistent with spec 
B-81 — problem with raw sensor data 

GENERATE SEQUENCE P ARAMS — need algorithmic solution — more detail 
B-109, R-6 — problem with order of activation 

END OF SESSION 1 
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Session 2: 9/17/93 9:30 a.m. - 11:30 a.m. 


High Level Diagrams 

B-l 19, R-7 — unclear how RENDEZVOUS is invoked 

B-73 - unclear function of RENDEZVOUS CNTL and RENDEZ V OU SCNTLSTORE 

B-98 — unclear need of P-Spec COPY CONTROL DATA — need to clarify and justify 

B-l 00, B-l 25 — copying and use of SUBFRAMECOUNTER is unclear 

B-81 — unclear function/need for STORE RAW SENSOR DATA 

B-84 — unclear function/need for INIT RUN PARAM STORE 

B-86 - unclear function/need of INIT GUIDANCE STATE STORE 

B-92, B-6, RIO - TS STATUS is not an input to TSP 

B-96, B-l 08, B-21 — inconsistent use of labels for bubbles for the functional units 

PATfoi RUN CCS 

B-70 — PAT seems to be changing SUBFRAME COUNTER — but should not 

B-71 — some processes that should be activated are not activated when ITH FRAME 2 and 
ITHFRAME5 

B-72 — some processes which should be activated are not from line 3 of PAT 

P Spec 1NIT GCS 

B-74 — used same label for stores and processes 
B-75 — ambiguous notation 

B-76, B-79 - problem with copying group flow names 

END OF SESSION 2 
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Session 3: 9/20/93 1:00 p.m. - 3:00 p.m. 


TSP 


B-7, B-19 — what is need/function of Data Expand and Data Compress? — appears that process is 
trying to manipulate names (same is true for ARSP, B-19; TDSP, B-140; TDLRSP, B- 
29; RECLP, B-226; GP, B-170; GSP, B-140; CRCP, B-193; CP, B-230; ASP, B-148; 
AECLP, B-198) 

B- 11-12 — need more explanation of approach to determine solid state temperature 

implicit assumption in the spec that M4>M3 and T4>T3 — > MAY WANT TO MOD 
SPEC 

B-135 — TS STATUS has not been checked for limits violations — > MAY NEED TO 
REWORD SPEC ON EXCEPTION HANDLING 

B-8 — problem with conditions involving THERMO TEMP for setting ATMOSPHERIC TEMP 
— may have introduced a condition that is not necessary 

all locals are real*4 as opposed to real*8 — where all reals in spec are real*8 — > MAY 
WANT TO MOD SPEC WITH REGARD TO PRECISION 


ARSP 


B-20, R-13 — need to provide more data for Shift Data and clarify 
need to consistently notate comments 

B-22 — problem with rotating/shifting data at right time — need to correct 

B-23, R-14 — notation is confusing/inconsistent 

B-121, B-15 — notation “.[previous value]” also confusing 

B-134 — Is it necessary to check all history variables; not clear which variables are being checked 
~> MAY NEED TO MOD SPEC 

B24 — AR FREQUENCY does not have 0 in the valid range — no need to check this variable 
since it is a RUN PARAMETER 

B25 — need to make sure AR_FREQUENCY*2 is in denominator — with given notation, it is not 
clear 

B-15, R- 18 — problem with first step in Newton Divided Differences — need to specify order 

B- 1 05 - need to specify order of subtraction 

R-19 — need to clarify references to indexes so that they are consistent — consistency between 
using “last” and “most recent” 
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R20 —is AR ALTITUDE checked for limit exceeded where it needs to be? 


B-82 — check on consistency of applying limit checks 
END OF SESSION 3 - — 


Session 4: 9/23/93 9:30 a.m. - 11:30 a.m. 

TDLRSP 

R-25 — reference to TDLR VELOCITYV seems to be a typo 

B-32 — seems that things are being rotated twice as often as necessary 

B- 130- 131 — not clear which time history is being checked for TDLR STATE, 
FRAMEBEAMUNLOCKED 

B-33, R-26 — FRAME BEAM UNLOCKED is not supposed to be changed (see line 2 Table 
5.11) 

B-34 — FRAME BEAM UNLOCKED needs to be set as per line 3 Table 5.11 — but it is not 

B-136 — some confusion about processing a table — > MAY WANT TO MOD SPEC 

B-32, R-27 — insufficient detail provided for calculating average beam velocities — need to give 
equations (also reference to table should be corrected) 

B-28 — TDLR STATUS is shown as input to TDLRSP - but it should not be 

B-126 — not clear where control loops must be 

TDSP 

B-141 — extra functionality present by having statement “TDS STATUS has bad value ...” 
END OF SESSION 4 


Session 5: 9/30/93 9:30 a.m. - 11:00 a.m. 

ASP 

B-156, R30 — locals are declared just as real — when some are real*8 
B- 158 — no apparent reason to make assignment of ATMOSPHERIC TEMP 
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B-159, R32 — when calculating abbreviations accel.* — it is not clear there is a matrix 
multiplication 

B-161 — need to check limits for AACCELERATION; also problem when all accelerations are 
equal when you go to calculate standard deviation 


GSP 


R-34 — G STATUS is not an input 

B-162 — there is no limit check for G STATUS 


END OF SESSION 5 


Session 6: 10/6/93 9:30 a.m. - 11:30 a.m. 


GP 

B-180 — variable END GCS is missing from the output section 

some control signals are being used in high-level diagrams — but they have not been seen 
at the lower-level p-specs. Why are some set and others not? 

not clear what is a comment and what is pseudo-code — the design should have a 
convention for comments and pseudo-code 

B-175 - need to use the simultaneous Runge Kutta method (Current design uses a sequential 
approach) 

B-176 — GP ROTATION matrix is not handled properly. 

B-179, B59 — combined tables 5.9 and 5.10 into 1 algorithm — but it is not done correctly. 

B-184, R-50 — CONTOUR VELOCITY array — this is not the right array to be searched. Also, 
numerous ambiguities in the description of the search 

B-186 — the computation of VELOCITY ERROR is done conditionally in the design — but 
should be done unconditionally 

B-188, R-52 — velocity error is not being calculated correctly 

B-189 — in determining contour crossed — in the conditional expression GP ALTITUDE <= 
ENGINES ON ALTITUDE and VELOCITY ERROR . 0 - this is not correct 

B-192 — the term optimal velocity is not explained 

B-190 — references to GP at 2.7 should be 2.6 
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B-178 — the term “tnow” has not been defined 


B-181, R45-46, R-48 — problem with limit checks 

B- 1 9 1 — in the description of doing Runge Kutta — the equations for the derivatives do not 
provide sufficient detail to be translated into code 


CRCP 


general comments — Expand/Compress functions not needed and title consistency 


END OF SESSION 6 


Session 7: 10/12/93 9:30 a.m -- 11:30 a.m. 

AECLP 

B-197, R-53 — not clear how to determine axial engine temperature 

B-215, R-60 — conditional (page 6) dealing with AE TEMP appears to be added functionality 
B-200, R-54 — problem with dimensions of arrays 

B-209, R-57 — check for upper bound of CONTOUR CROSSED is not correct; also general 
problems with limit checks 

B-201, R-55-56 — need absolute values in calculating THETA 
B-212 — THETA is declared as a local variable — but THETA is in a global data store 
B-202 — calculation of limiting pitch error is unnecessarily broken down into 2 steps 
B-204 — equation for Q TEMP is incorrect 

B-205, R-58 — error in calculating TE LIMIT — does not properly reflect bounding process 
B-214 — the nested Ifs may not be verifiable/modifiable 

B-206 — problem with correctly giving error messages (unnecessary duplication of error 
messages) 

B-216 - 3 variable, PITCH ERROR, YAW ERROR, and THRUST ERROR are needlessly set 
there - but not used 

B-210 — introduces INT CMD — not necessary 
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B-2 11— need to show derivation of TELIMIT 
B-207 — does not show rounding of AECMD 

RECLP 

R-61 — RE STATUS is shown as an input - but should not be 

B-220 — problem with notation of G ROTATION 

B-222, R-62 — need additional detail in determining roll engine command 

B-224 — PI is not defined 

B-225 — problems with limit checking regarding THETA and missing for RE CMD, 
RESTATUS 

B-221 — reference to Fig 5.1 pg 60 is not correct 

B-223 00 need to define term “lowest bit” (need more precise description) 

B-2 19 — duplication of giving error message 

END OF SESSION 7 


Session 8: 10/14/93 1:30 p.m. — 3:30 p.m. 

CP 

B-254 — remove stuff (like end of CP P-spec) that is not necessary 

B-232 - ITH FRAME 2 and ITH FRAME 5 , and NBYTES and BYTEPACKET are missing 
from input/output section 

B-249 — BYTE PACKET is not accurately defined in data dictionary 

B-259 — need to define notation “B” used in defining INIT SAMPLE MASK 

B-240 — GP ROTATION and KMATRIX are missing from the packet variables table 

B-243 — KALT and K MATRIX are missing from the list of variables for sample mask when 
ITH FRAME 2 is true and ITH FRAME 5 is false 

B-244, B-252-253 — the variables to be loaded are ambiguously described 

B-25 1 — bits for K ALT and K MATRIX are missing 
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B-255 — uses SUBFRAMECOUNTER — which is not defined — should be 
SUBFRAMECOUNTER 

B-245 — insufficient detail in determining the total number of bytes 

B-242, B-257 — comment refers to “lower” 16 bits of CHECKSUM — but CHECKSUM has only 
16 bits — comment needs to be more precise 

B-258 — the action to set C STATUS to healthy is not done to calculating CFIECKSUM and 
loading BYTE PACKET 

B-246 — when K MATRIX and/or GP ROTATION are loaded — these are supposed to be stated 
in a special way and the design does not address this - but need to 

B-247 — the design is not specific about which history variables are being loaded 

B-248 — need a better explanation of getting masks and packets 

R-63 — several variables are shown as input on the CFD/DFD but are not shown in the spec as 
input 

should not have 2 different P-Specs for Expand (it appears that one is never called) 

B-238 — CFD/DFD does not show packet going into GUIDANCE STATE 
CRC 

B-264, R-73 — need to reference or derive the CRC- 16 algorithm 

the statement that says that CRC- 16 must be calculated at each call is false — it should be 
removed 

B-262 — need to define “logical shift” 

B-263-264 — need to make description of forming CRC more precise 

B-261 — need more precision in the description of forming the table — spell out all steps 

END OF SESSION 8 


Session 9: 10/15/93 8:30 a.m. - 10:30 a.m. 

IMPORTANT NOTE: DESIGN DOES NOT BALANCE. 

According to the Software Development Standards for the Design Process, the Design should 
have been balanced prior to bringing it to Design Review. This, of course, explains the many 
many problems we have found. 

Data Dictionary 

B-12 — EXTERNAL data store not consistent with spec 
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B-l 1 — GUIDANCESTATE is missing from the data dictionary 

B-14 — RETNPARAMETERS and SENSOR OUTPUT are missing from the data dictionary 
Lots of miscellaneous stuff: 

B-l 02, 268, 166, 228-229, 164-165, 238 — See inspection logs for individual entries with 
problems 

Introduction 

B-39 — in the top level description, the term “four phases” is not accurate 
B-41 — need to improve clarity of Module Descriptions 
B-43 — need to state which version of the spec this design complies with 
B-l 03 — clarify statement “code of the design” 

B-l 04 — need to refer to spec and mods appropriately 

B-45 — do not need a status section 

B-47, B49, B122 — need to clean up notation 

B-l 1 1 — need to include a description of the call structure 

B-l 12 - need to include an overview of scheduling procedures 

B-l 16 — need a section describing the syntax for the pseudocode 
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C.1.2 Review Logs from Preliminary Design Review 
Review Log from System Analyst 

Individual Inspection Preparation Log #1 (page 1) 

October 15, 1993 
October 15, 1993 


INDEX 

Introduction 

Structured Analysis Diagrams 
Data Dictionary 
INITGCS, P-Spec 1 
AECLP, P-Spec 2.1 
ARSP, P-Spec 2.2 
ASP, P-Spec 2.3 
CP, P-Spec 2.4 
CRCP, P-Spec 2.5 
GSP, P-Spec 2.6 
GP, P-Spec 2.7 
RECLP, P-Spec 2.8 
TDLRSP, P-Spec 2.9 
TDSP, P-Spec 2.10 
TSP, P-Spec 2.11 

Miscellaneous P-Specs (not the eleven functional units) 
Miscellaneous 

Typographic Errors, Style, Grammar 
Suggestions for the Future 


Name: Bernice Becher Date Log Submittedi 

Implementation: Pluto Date of Inspection 

Role: Inspector 

Defects/Clarity Problems/Concems 
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INTRODUCTION 

Introduction, page 1 

1.1 Top-Level Description, all items with "*)" 

Question: What does "*)" mean? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction, page 1 

1.1 Top-Level Description, first "*)" item "four phases" is not accurate. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

(see Software Requirements Figure 1.2 and Table 5.10) 

Introduction, page 2 

1.3 Module Descriptions, third paragraph. Question: What does "empirical notations" mean? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction, page 3 

2.4 Transition History, second statement. 

This statement does not include the fact that the code of the design should conform to the GCS Software 
Requirements document 2.2 and all existing formal modifications (1-26) to the Software Requirements 
document. 

*Requirement: Reference: Software Develpment Standards, "Software Design Standards", "Design 

Documentation", "III Transition History", "If changes, additions, or deletions are made in response to a 
formal modification, the formal modification number should be referenced." *Requirement: 
Completeness (Reference: DO-178B 11.0b) 

Introduction, page 3 

2.4 Transition History, second statement. Question: What does "code of the design" mean? 
*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction, page 3 

2.4 Transition History 

No mention was made of changes to the design to comply with the Software Development Standards. 

Were there any changes to the design made in response to this requirement? If so, they should be 
mentioned in the transition history, as per this requirement. 

*Requirement: Software Development Standards, "Instructions to Programmers Regarding the Transitional 
Design Phase", #1, "Modifying the orignial design. ..so that the new detailed design meets. ..the 
standards set forth in this document in the chapter "Software Design Standards"". 

Introduction, page 4 
2.6 References 

The reference "GCS Development specifications" is not the correct name for the specification document 
and does not include the version number of the document. In addition, this statement does not include 
the numbers of all existing formal modifications (1-26) to the Software Requirements document. 
*Requirement: Completeness (Reference: DO-178B 11.0b) 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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Introduction, page 5 45 

3. Status of Pluto GCS Design, first paragraph 

"The pluto version ... has the GCS modification number 1 to the 2.1 Release. ..incorporated into it." 

The meaning of this statement is not clear. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction, page 5 46 

3. Status of Pluto GCS Design, second paragraph 

The reference "version 2.2 of the GCS Development specifications" is not the correct name for the 
specification document. In addition, this statement does not include the fact that the design should 
have been modified to also incorporate all existing formal modifications (1-26) to the Software 
Requirements document. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction, Pages 6-7: 47 

4. Notation in Pluto Version of GCS Design 

It is not clear what the following mean: 

"the * oldest", 

"the * FIFO", 

"does * not" 

"noun * indicates" 

"body * axis" 

"performed * three" 

"an array * with" 

"performed * four times" 

"array, * independently" 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction, pages 6-7 49 

4. Notation in Pluto Version of GCS Design 

Page 6, last comment box, and page 7, first and last comment box It seems the design is using 
one notation, namely to mean two different things (3 lander body axes as well as three 
independent calculations). Is this what was intended? Also, is "three times on each of the three 
elements in the vector..." intended to mean nine times? Is "four times on each of the four 
elements in the array" intended to mean sixteen times? That's probably not the intention, but is 
the meaning. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction, page 6 122 

4. Notation in Pluto Version of GCS Design 

Page 6, last comment box "Also, anlndividual element of a vector can be referenced using the 
following notation: GP VELOCITY.x " Problem: It is not clear what this notation means. Does 
",x" mean ",x" or ",y" or ".z", and if so, exactly what does each represent? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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Introduction 111 

Description of Call Structure 

The software structure needed to implement the requirements is missing from the design document. 

Even though some of the software structure is implicit in the DFDs and the PATs, a description as 
described in the reference below is missing. 

*Requirement: Reference: Software Development Standards, "Software Design Standards", "II. Design 
Structure", "a)Description of Call Structure". 

*Requirement: Reference:DO-178B, 11.10b 

Introduction 112 

Scheduling 

An overview of the scheduling procedures is not contained in the design document. Even though the 
scheduling is implicit in the DFDs and PATs, the overview is missing. *Requirement: 

Reference Software Development Standards, "Software Design Standards", "II. Design Structure", "d) 
Scheduling". 

*Requirement: Reference :DO-178B, 11.1 Of 

Introduction 123 

An overview of the flow of control for any given frame is not contained in the design document. Even 
though this flow of control is implicit in the DFDs and PATs, the overview is missing. What is 
especially needed is a discussion of the invocation of the Individual subframes, the invocation of 
rendezvous, and the ending ofGCS. *Requirement: Reference:DO-178B, 11.1 Of 

Introduction 115 

Comments on Method 

Discussion is missing concerning which structured analysis/design method was used. *Requirement: 

Follow a particular design method (References: Software Development Standards, "Software Design 
Standards", "Design Methods, Rules, and Tools", "...using the structured analysis ...by Hatley and 
Pirbhai or...", and "Design Documentation", "...document should follow.. .GCS specification or the 
Hatley book...") 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Introduction 116 

Syntax for Pseudocode 

An explanation of the syntax used in the pseudocode in the P-Specs is not present in the design. It is 
not important what type of pseudocode or structured English is used, but it is very important that the 
pseudocode be completely unambiguous. The inspection of the design is hampered unless the syntax 
is unambiguous. 

In order to insure that the pseudocode is unambiguous, the design should supply either a reference to a 
source which describes the syntax in detail, or should itself supply a detailed description of the syntax. 

This design has not done so. The designer, during the overview meeting, stated that the pseudocode 
followed Fortran 77, and in some cases it does, but unfortunately there are exceptions: 
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1. The design frequently uses the construct which is not strictly FORTRAN 77: 

if (expression 
) statement 
statement 
statement 
endif 

2. The design uses "==" which is not FORTRAN syntax. 

3. In some cases, as for example in P-Spec 2.2.3, page 3, the design uses plain Engish text in the 
middle of a nested if. 

4. The design stretches nested ifs over several pages, which is difficult to follow. 

5. It is not always clear what is a comment and what is actually part of the design. Sometimes, 
the comments are boxed in with *, but sometimes they are not. An example of this is 
TDLRSP, P-Spec 2.9.2, pages 3 and 4. The design seems to use single asterisks for 
comments sometimes but never explicitly states the syntax for a comment. Sometimes a 
comment is the only entry inside an else or else if clause, and it is not completely clear if 
this means the clause is null. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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STRUCTURED ANALYSIS DIAGRAMS 

Context Diagram GCS and Data Dictionary entries for 1 

INITIALIZATIONDATA and for INITENDGC S 

In the context diagram there is a solid arc labeled INITIALIZATION DATA. This element has the 
same name as a data flow name in the Software Requirements document. There is some confusion 
because the data flow name in the design includes "INITENDGCS" which is not in the Software 
Requirements document. This in itself may not be a requirement violation, but it is confusing. There 
is, however, another problem. INIT END GCS is listed in the dictionary as a control flow. It is 
included in the group flow name INITIALIZATION DATA which is a data flow name and appears on 
the GCS Context Diagram as a data flow. The control flow INIT END GCS should not be included 
on a solid data flow line. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Context Diagram GCS 2 

The bubble INITRUNGCS does not show as input the variables FRAMECOUNTER and 
SUBFRAMECOUNTER coming from GCSSIM. These need to be shown as input for every frame 
and subframe after the initialization frame and subframe because the simulator updates them after each 
frame/sub frame respectively, (see Software Requirements document, Figure 2.2) 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

Context Diagram GCS 3 

The bubble INIT RUN GCS does not show the variables AESWITCH and RE SWITCH as output to 
the engines. These variables control the turning on/off of the axial engines and the turning off of the 
roll engines, (see Software Requirements document. Figure 2.3) 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

*Addition 09/22/93 (revised 9/27/93) 

Context Diagram GCS and DFD/CFD INIT RUN GCS 167 

(see #3 and #51) 

It turns out that AES WITCH and RES WITCH do not need to appear on the context diagram at all 
because they are in not in the EXTERNAL data store. They are merely used internally in the GCS 
software; therefore #3 and #51 can be canceled. 

DFD/CFD INIT RUN GCS 50 

The bubble RUNGCS does not show the variables FRAME COUNTER and 
SUBFRAME COUNTER as input coming from GCS SIM. These need to be shown as input for 
every frame and subframe after the initialization frame and subframe because the simulator updates 
them after each frame/subframe respectively. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

DFD/CFD INIT RUN GCS 51 

The bubble RUN GCS does not show the variables AE SWITCH and RE SWITCH as output to the 
engines. These variables control the turning on/off of the axial engines and the turning off of the roll 
engines. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 
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DFD/CFD INIT RUN GCS 16 

The data stores RUNPARAMETERS, GUIDANCE STATE and SENSOR_OUTPUT and the flows 
into and out of them are missing from this diagram. These stores should appear because the data 
moves from INIT GCS to RUNGCS through these data stores, (see Requirements document. Figures 
2.4 and 2.5) 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

DFD/CFD INIT RUN GCS 52 

Data flows into and out of the EXTERNAL store are missing, (see Software Requirements document. 

Figures 2.4 and 2.5) 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

DFD/CFD INIT RUN GCS 124 

The solid arc labeled RAW SENSOR DATA should not flow directly from outside to RUN GCS. (see 
Requirements document. Figures 2.4 and 2.5) 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

PAT INIT RUN GCS 17 

Second line of table: "START GCS INIT DONE RUN DONE 1 3 2" 

Question: Since this is merely the line that lists the input names, what is the meaning of the right side of 
the second line with "13 2"? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

PAT INIT RUN GCS 109 

Fifth line of table: '’"TRUE" "TRUE" "FALSE" 0 1 1" 

Problem: This line shows that the order of activation of GENERATESEQUENCEPARMS and 
RUN GCS doesn't matter; however, the INIT END GCS DFD shows that for a given frame, 

GENERATE SEQUENCE PARMS must be executed before RUN GCS because the variables 
ITH FRAME 2 and ITH FRAME 5 flow from GENERATE SEQUENCE PARMS to RUN GCS. 
*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

DFD/CFD RUN GCS 67 

On this diagram, SUBFRAMECOUNTER appears as a control flow as input and output to the cspec 
and as input to SUBFRAME COUNTER STORE. Problem: In the data dictionary, 

SUBFRAME COUNTER is a data flow. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

DFD/CFD RUN GCS 98 

It is not clear what is the purpose of the process "COPY CONTROL DATA" or whether it is actually 
needed at all. If it is the case that it has a function, it is not clear whether that function is traceable to 
the Software Requirements document. 

“"Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 
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DFD/CFD RUN GCS 81 

The top left-hand bubble labeled "STORE RAW SENSOR DATA" seems to perform no useful function. 

The raw sensor data is included in the group flow INITIALIZATIONDATA which means it is initialized 
by the simulator. In addition, in the Software Requirements document. Figure 2.2, it is shown that the raw 
sensor data comes into GCS from the external sensors. There is therefore no requirement for GCS to put 
the raw sensor values into any data store, as they are already in the global data store EXTERNAL at the 
beginning of each frame. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DFD/CFD RUN GCS 84 

The top middle bubble labeled "INIT RUN PARAM STORE"seems to perform no useful function. The run 
parameter data is included in the group flow INITIALIZATION DATA which means it is initialized by the 
simulator. In addition, in the Software Requirements document. Figure 2.4, it is shown that the ran 
parameter data is put into the store RUNPARAMETERS by INIT GCS which (according to the LEVEL 2 
SPECIFICATION in the Software Requirements document) is "actually a part of 
GCSSIMRENDEZVOUS"). Figure 2.4 also shows that RUN GCS does not store into the data store 
RUN PARAMETERS. There is therefore no requirement for GCS to put the run parameter data into any 
data store, as they are already in the global data store RUN PARAMETERS at the beginning of each 
frame. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DFD/CFD RUN GCS 86 

The top right-hand bubble labeled "INIT GUIDANCE STATE STORE" seems to perform no useful 
function. The guidance state data (with the exception of 1NTERNAL CMD which is not used as an input) 
is included in the group flow INITIALIZATION DATA which means it is initialized by the simulator. In 
each frame, all of the data in the GUIDANCESTATE store will be output by GCS. There is therefore no 
requirement for GCS to put the guidance state data into any data store as they are already in the global data 
store GUIDANCE STATE at the beginning of each frame. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DFD/CFD RUN GCS 92 

Input to TSP from GUIDANCE STATE store with group flow name TEMP GS IN (which is element 
TS_STATUS) is incorrect. TS_STATUS is not an input to TSP. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

DFD/CFD RUN GCS 96 

The labels on the eleven bubbles which represent the eleven functional units in the Software 
Requirements document are not exactly the same as the labels on the DFD/CFDs one level down, 
and this causes confusion. For example, the bubble for P-Spec 2.2 is "ARSP ALTIMETER 
RADAR", while the name one level down is "ARSP - Altimeter Radar Data Expand and 
Compress". The names for TDLRSP and TSP also do not match the names ones level down. 
*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Rcquirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and ll.Od) 

* DFD/CFD RUN GCS 166 

The two bubbles at the bottom of the page, namely SEND CHUTE RELEASE COMMAND and SEND 
ENGINE DATA do not seem to perform any function. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 
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*Addition 09/22/93 (DELETED 9/27/93 - NEED REVISION TO SPEC - PUT 
CHUTE RELEASED INTO EXTERNAL DATA STORE) 

DFD/CFD RUN GCS 168 

It may be that CHUTERELEASE in the left-hand bottom comer should not appear on the diagram at 
all because it is in the GUIDANCESTATE store rather than in the EXTERNAL store. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

* DFD/CFD RUN GCS 169 

Question: In the bottom left-hand corner, the input to SEND ENGINE DATA is AERECMDS, 
while the output is ENGINE DATA. Both flows contain the same data. Why are two different names 
used? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

* DFD/CFD RUN GCS 144 

Input to GSP from GUIDANCE STATE store with group flow name GYRO GS IN (which is element 
GSSTATUS) is incorrect because GSSTATUS is not an input to GSP. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

* PAT RUN GCS 229 

There doesn't seem to be any mechanism for the eleven functional units to signal when they have 
finished executing activating continuously once they have been activated once. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

PAT RUN GCS 97 

The process "COPY CONTROL DATA" which appears on the DFD/CFD for RUN GCS is missing 
from this PAT, and therefore its order of activation is unknown. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

PAT RUN GCS 68 

Problem: In the first subframe (the first four lines of the table), this PAT has imposed an order of 
activation on the processes that is not stated in the Software Requirements document. The Software 
Requirements document does not state any specific order of activation for ARSP, TDLRSP, TDSP, 

ASP, or GSP with respect to each other; however, the PAT imposes an arbitrary order of activation. 
*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

**Software Requirements 2.2 with Mods 1-26 Reference: Chapter 4, Level 3 Flow Diagrams and C- 
Specs, Scheduling 

PAT RUN GCS 69 

Problem: In the third subframe (the last two lines of the table), this PAT has imposed an order of 
activation on the processes that is not stated in the Software Requirements document. The Software 
Requirements document does not state any specific order of activation for AECLP and RECLP with 
respect to each other; however, the PAT imposes an arbitrary order of activation. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

**Software Requirements 2.2 with Mods 1-26 Reference: Chapter 4, Level 3 Flow Diagrams and C- 
Specs, Scheduling 
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PAT RUNGCS 70 

Problem: The variable SUBFRAMECOUNTER appears in the output section of this PAT, and its 
value is therefore changed by the c-spec. This is not permitted. The Software Requirements document 
states in the section labeled LEVEL 2 SPECIFICATION that SUBFRAME COUNTER will be 
initialized by INIT GCS which is actually a part of GCSSIMRENDEZVOUS. The Software 
Requirements document also states in Chapter 4. LEVEL 3 FLOW DIAGRAMS AND C-SPECS, 
under SCHEDULING, that "On the first, and subsequent, calls to GCS_SIM_RENDEZVOUS, 

FRAME COUNTER and SUBFRAME COUNTER will be returned to the implementation 
containing the correct values for operation. There is no requirement anywhere in the Software 
Requirements document that the GCS software should change the value of SUBFRAME COUNTER. 
*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

**Software Requirements 2.2 with Mods 1-26 Reference: Chapter 4, Level 3 Flow Diagrams and C- 
Specs, 

PAT RUN GCS 125 

Problem: The use of the name "SUBFRAME COUNTER" is ambiguous because it appears in the 
stores EXTERNAL OLD, SUBFRAMECOUNTERSTORE, and in the global store EXTERNAL 
(defined in the Software Requirements document but not in the store EXTERNAL in this design 
document). One can look at the RUN GCS DFD and deduce that the intention is to store into 
SUBFRAME COUNTER STORE, but the P-Spec itself should be self-contained. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

**Software Requirements 2.2 with Mods 1-26 Reference: Chapter 4, Level 3 Flow Diagrams and C- 
Specs, 

PAT RUN GCS 71 

The first line of the table, where ITH FRAME 2 IS F and ITH FRAME 5 is F: 

Problem: Some processes which should be activated are not activated. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Chapter 4, Level 3 Flow Diagrams and C- 
Specs, 

PAT RUN GCS 72 

The third line of the table, where ITH FRAME 2 IS F and ITH FRAME 5 is "TRUE": 

Problem: Some processes which should be activated are not activated. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Chapter 4, Level 3 Flow Diagrams and C- 
Specs, 

PAT RUN GCS 73 

It is unclear, looking at the input and output columns for RENDEZVOUSCNTL, how it functions. 

Question: How does the functioning of RENDEZVOUS CNTL work? if WAITING= rendezvous 
was called, then what does RUNNING mean? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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*PAT RUNGCS 228 

Under output column, "GPHASRUN", the value "DONT CARE" appears. This is not feasible. 

Normally "DONT CARE" represents any value for an input (it is not an actual value to be set on 
output). Note that the data dictionary only shows two values, namely "TRUE", and "FALSE" for 
GPHASRUN. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

*PAT RUN GCS 164 

There doesn't seem to be any mechanism for keeping the eleven functional unit processes 
from activating continuously once they have been activated once. There does not seem to be 
a way that they signal when their execution has completed so that they can be deactivated. 
*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

* PAT RUN GCS 165 

The processes "SEND CHUTE RELEASE COMMAND" and "SEND ENGINE DATA" do not seem 
to be traceable to the specification, (see #138) (see specification Figure 2.4 which shows data going 
off page) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

* DFD/CFD GSP 143 

Input to TDSP with group flow name GYRO GS IN (which is element GS STATUS) is incorrect 
because G STATUS is not an input to GSP. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

* DFD/CFD CP 234 

The following show as inputs to CP P-Spec 2.4.2, but are not actually inputs: 

AESWITCH 

CSTATUS 

RESWITCH 

TDLRSPSWITCH 

TDSPSWITCH 

TE LIMIT THETA 

FRAME BEAM UNLOCKED 

FRAMEENGINESIGNITED 

INTERN AL CMD CL 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

* DFD/CFD CP, and DFD/CFD RUN GCS 238 

The variable PACKET is shown correctly as an output from CP, but the fact that it is also an output that 
goes into the GUIDANCE STATE data store has not been shown on the diagrams. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

* DFD/CFD CP, and DFD/CFD RUN GCS 239 

The variable SUBFRAME COUNTER is shown correctly as an input to CP, but the fact that it is also 
an input that comes from the EXTERNAL data store has not been shown on the diagrams. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 
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DATA DICTIONARY 


DATA DICTIONARY 12 

EXTERNAL 

The actual data elements and order of the data elements in the store EXTERNAL do not agree with 
those in the Software Requirements document. Question: Why are the elements repeated several 
times? *Requirement: Fullfillment of requirements in Software Requirements document (References: 

DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, under Requirements, under 
Global Data Store Organization. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

DATA DICTIONARY 1 1 

GUIDANCESTATE 

The store named GUIDANCE STATE is missing from the data dictionary, even though it does appear 
on the RUNGCS DFD/CFD, and descriptions of some elements in the design data dictionary state 
that they are in this store. It is therefore not possible for the inspector to check whether the data in this 
store is of the right data type and dimension, or whether the elements occur in the proper order. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, under Requirements, under 
Global Data Store Organization. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

DATA DICTIONARY 14 

RUNPARAMETERS 

The store named RUN PARAMETERS is missing from the data dictionary, even though it does 
appear on the RUN GCS DFD/CFD, and descriptions of some elements in the design data dictionary 
state that they are in this store. It is therefore not possible for the inspector to check whether the data 
in this store is of the right data type and dimension, or whether the elements occur in the proper order. 
*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, under Requirements, under 
Global Data Store Organization. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

DATA DICTIONARY 
SENSOROUTPUT 

The store named SENSOR OUTPUT is missing from the data dictionary, even though it does appear 
on the RUN GCS DFD/CFD, and descriptions of some elements in the design data dictionary state 
that they are in this store. It is therefore not possible for the inspector to check whether the data in this 
store is of the right data type and dimension, or whether the elements occur in the proper order. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, under Requirements, under 
Global Data Store Organization. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 


C-23 



Individual Inspection Preparation Log #1 (Page 13) 

Name: Bernice Becher Date Log Submitted: October 15, 1993 

Implementation: Pluto Date of Inspection October 15, 1993 

Role: Inspector 

Defects/Clarity Problems/Concems 

DATA DICTIONARY 

Use of Design-defined Control Stores 102 

The following control stores (which are not defined in the Software Requirements document data 
dictionary) appear in the design data dictionary: 

*END_GCS_STORE 

EXTERNALOLD 

GENERATESEQUENCEPARMS 

*GP_HAS_RUN_STORE 

GUIDANCESTATEOLD 

INITGCS 

*RENDEZVOUS_CNTL_STORE 

RUNGCS 

RUNPARAMETERSOLD 

SENSOROUTPUTOLD 

* SUBFRAMECOUNTERSTORE 

* = used in design 


Problem 1: Only four of the above (ENDGCSSTORE, GPHASRUNSTORE, 

RENDEZ V OU SCNTLST ORE, and SUBFRAME COUNTER STORE) appear on the structured analysis 
diagrams in the design. It is not clear why these four stores are needed and exactly how they are used. 
*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Problem 2: It seems that the seven stores listed above which are not used at all should not be in the data 
dictionary. *Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DATA DICTIONARY 268 

The following entries are not used: 

AECLPDONE 

ARSPDONE 

ASPDONE 

CLPDONE 

CPDONE 

CRCPDONE 

GPDONE 

GSPDONE 

RECLPDONE 

RENDEZVOUS 

SPDONE 

TDLRSPDONE 

TDSPDONE 

TSPDONE 

DATA DICTIONARY 269 

TDLR ANGLES and THETA 
In RANGE, "PI" is not defined. 

DATA DICTIONARY 

ARFREQUENCY 267 

RANGE upper value "2.45**9" is incorrect. 
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DATA DICTIONARY 195 

AXENGGSIN 

GPATTITUDE is an input to AECLP but is missing from AX_ENG_GS_IN. AE STATUS is 
not an input to AECLP and therefore should not be included in AX ENG GS IN. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

DATA DICTIONARY 196 

AXENGRPIN 

DELTA T is an input to AECLP, but is missing from AX ENG RP IN. GRAVITY is an input to 
AECLP, but is missing from AX ENG RP IN. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

DATA DICTIONARY 

AXENGRPIN 55 

Doesn't state whether control or data flow 
*Requirement: Completeness (Reference: DO-178B 11.0b) 

DATA DICTIONARY 

BYTEPACKET 56 

BYTEPACKET is defined to be 188 of integer* 1 which does not match the global data store 
variable PACKET which is 256 of integer*2. Also there is no type integer* 1 in Fortran. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

CHECKSUM 57 

The only attribute is the data type. More information is needed for understanding. *Requirement: 
Completeness (Reference: DO-178B 11.0b) 

* DATA DICTIONARY (and Context Diagram GCS, DFD/CFD INIT RUN GCS, DFD/CFD 197 

RUN GCS, DFD/CFD CRCP) 

CHUTERELEASE 

The name CHUTE RELEASE is the same as CHUTE RELEASED (except the first is a control 
flow and the second is a data flow). 

Question: Why are they both required? 

* DATA DICTIONARY 235 

COMM EXT IN SUBFRAME COUNTER is missing 

* DATA DICTIONARY 236 

COMMEXTOUT 

This entry seems to be unnecessary as it does not appear to be used anywhere. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

* DATA DICTIONARY 237 

COMMG SIN 

The variables C STATUS and CL should not be included. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 
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* DATA DICTIONARY 233 

ROLENGGSIN 

The variable RE STATUS is not an input to RECLP, but it has been included in ROL ENG GS IN. 
*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

DATA DICTIONARY 

EXTERN ALDATA 58 

This is equivalent to FRAMECOUNTER only. It seems misleading to name it 
EXTERNAL DATA and equate it to FRAME COUNTER. What is its purpose? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DATA DICTIONARY 

FRAMECOUNTER 54 

The attribute is data but it is shown as "data/control flow". Why is this? It does not appear on 
any diagrams as control. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

DATA DICTIONARY 

GENERATE SEQUENCE PARMS (store) 60 

"*not-defined*" 

Question: What does "not-defined" mean, and why is this element in here? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DATA DICTIONARY 2 1 1 

GUIDESOIN 

ATMOSPHERICTEMP is not and input to GP, and therefore should not be included in 
GUIDESOIN 

DATA DICTIONARY 2 1 2 

GUIDEGSOUT 

TE INTEGRAL and CL are outputs from GP, but are missing from GUIDE GS OUT. 

DATA DICTIONARY 90 

GUIDANCE STATE DATA and INIT GS OUT 

Question: What is the reason for having two group flow names which contain exactly the same 
elements? It seems to overly complicate the design and make it more difficult to understand. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

INITENDGCS 4 

This element has only one entry in the dictionary, namely "FALSE". The dictionary does not state 
what this entry is or what it means. It does not have brackets around it. Is it the range, or the 
initial value, or a constant? Can it assume only one value? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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DATA DICTIONARY 

INITEXTOUT 61 

"*not-defmed*" 

Question: What does "not-defined" mean, and why is this element in here? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 1 1 .Of) 

DATA DICTIONARY 

INITGCS 62 

"*not-defmed*" 

Question: What does "not-defined" mean, and why is this element in here? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 1 1 .Of) 

DATA DICTIONARY 91 

INITGSOUT 

This group flow name contains two element names which are not in the data dictionary, namely 
TDLRSP SWITCH and TDSP SWITCH. It also is missing one data flow name, namely CL. 
*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 
*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

DATA DICTIONARY 
ITHFRAME2 and ITH FRAME 5 

Question: What is the meaning for "TRUE/FALSE"? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

NBYTES 65 

"*integer*" 

No information is given other than "*integer*". What is this element for? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 83 

RAW SENSOR DATA and RAW SENSOR EXT OUT 

Question: What is the reason for having two group flow names which contain exactly the same 
elements? It seems to overly complicate the design and make it more difficult to understand. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

RENDEZVOUSCNTL 120 

Some description of the meaning of this variable is needed. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

* DATA DICTIONARY 218 

ROLENGGSOUT 

The variable RE SWITCH is not an output from RECLP, but it has been included in 
ROL ENG GS OUT 
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DATA DICTIONARY 

RUNGCS 66 

"*not-defmed*" 

What does "not-defined" mean, and why is this element in here? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DATA DICTIONARY 89 

RUNPARAMETERDATA and INIT RP OUT 

Question: What is the reason for having two group flow names which contain exactly the same 
elements? It seems to overly complicate the design and make it more difficult to understand. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

STARTGCS 5 

The dictionary gives the values FALSE, TRUE, and DONT CARE but does not give the 
meanings for these. This causes confusion in understanding IN1T RUN GCS PAT. It is not clear 
until one studies INITRUNGCS PAT whether TRUE means that GCS is to be activated or 
whether it means that it has already been activated. By deduction, it appears to mean that it should 
be activated. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

SUBFRAMECOUNTERSTORE 101 

This is a data store which contains the element named SUBFRAMECOUNTER. The global data 
store defined in the Software Requirements document as EXTERNAL contains a data element 
named SUBFRAME COUNTER. This duplication of names causes ambiguity, (see P-Spec 2.18) 
*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

TDLNDRADRPIN 95 

This group flow name appears on the RUN GCS DFD/CFD as input to TDLRSP. The group 
name incorrectly includes KMATRIX and TDLRSTATE which are inputs to TDLRSP, but are 
not in the RUN PARAMETERS store but rather in the GUID AN CE ST ATE store. (K MATRIX 
has already been correctly included in the group flow name TDLNDRADGSIN) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DATA DICTIONARY 

TDLNDRADGSIN 94 

This group flow name appears on the RUN GCS DFD/CFD as input to TDLRSP. The group 
name incorrectly includes TDLR STATUS which is not an input to TDLRSP. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DATA DICTIONARY 

TDLNDRADGSIN 127 

TDLR STATE is missing from this list of inputs from GUID ANCEST ATE to TDLRSP. 
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DATA DICTIONARY, pages 3 1 and 32 9 

TDLRSPSWITCH 

TDLRSPSWITCH is not a GCS common store variable and is not in the Data 
Dictionary but is listed under GUIDANCESTATEDATA and under 
GUIDANCE_STATE_OLD.(SEE FORMAL MODIFICATION 2.2-24.5) 

*Requirement: Follow a particular design method (References: Software Development 
Standards, "Software Design Standards", "Design Methods, Rules, and Tools", "...using 
the structured analysis ...by Hatley and Pirbhai or...", and "Design Documentation", 

"...document should follow.. .GCS specification or the Hatley book...") 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 
11. Of) 

DATA DICTIONARY, pages 3 1 and 32 10 

TDSPSWITCH 

TDSPSWITCH is not a GCS common store variable and is not in the Data Dictionary 
but is listed under GUIDANCE STATE DATA and under 
GUIDANCE_STATE_OLD.(SEE FORMAL MODIFICATION 2.2-24.6) 

*Requirement: Follow a particular design method (References: Software Development 
Standards, "Software Design Standards", "Design Methods, Rules, and Tools", "...using 
the structured analysis ...by Hatley and Pirbhai or...", and "Design Documentation", 

"...document should follow.. .GCS specification or the Hatley book...") 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 
11. Of) 

DATA DICTIONARY 

TEMPGSIN 93 

This control flow name is not required. TS STATUS is not an input to TSP (as is 
incorrectly shown on the RUN GCS DFD (see # 92) 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 

DATA DICTIONARY 139 

The primitive elements which are in the design data dictionary but are not in the Software 
Requirements data dictionary in general do not contain enough information for their meaning 
and use to be unambiguous. Each should contain as a minimum a general description, the 
units, the name of the control store (if any) in which it appears, and if logical or boolean the 
meaning of the values. It would also be helpful to have the "USED IN" item, and the data 
type. 
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INITGCS P-Spec 1 

INITGCS, P-Spec 1, and Data Store INIT GCS 74 

There is confusion regarding the fact that there is a process named INIT GCS and a data store named 
INIT GCS (which is not used anywhere). *Requirement: Nonambiguity (Reference: DO-178B 1 1.0a). 

INIT GCS, PSpec 1, page 1, middle of page 75 

"copy INITIALIZATIONDATA.RUNPARAMETERDATA.* to RUNPARAMETERDATA.*" 

"copy INIT I ALIZ ATIOND AT A .GUID AN CEST ATE D AT A. * to GUID AN CEST ATE D AT A. * " 
ProbleimThe notation INIT1ALIZATIONDATA.RUNPARAMETERDATA, 

INITIALIZATION DATA.GUIDANCE STATE DATA, is not defined or explained anywhere. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

INIT GCS, P Spec 1, page 1, middle of page 76 

"copy INIT I ALIZ ATIOND AT A .RUNP ARAMETERD AT A . * to RUNPARAMETERDATA.*" 

"copy INITIALIZATIONDATA.GUIDANCESTATEDATA.* to GUID AN CEST ATED AT A. * " 

Problem: Neither one of these statements is feasible. 

INITIALIZATIONDATA, RUNPARAMETERDATA, and GUID AN CESTATED AT A are 
merely group flow names. None of them is a data store, so how can any data be copied? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

INIT GCS, P Spec 1, page 1, middle of page 77 

"copy INIT I ALIZ ATIOND AT A .RUNP ARAMETERD AT A . * to RUNPARAMETERDATA.*" 

"copy INIT I ALIZ ATIOND AT A .GUID AN CEST ATED AT A. * to GUID AN CEST ATED AT A. * " 

Problem: The copying of INITIALIZATION DATA (the group flow name from the 
Software Requirements document) is not a function which can be traced to the Software Requirements 
document. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

INIT GCS, P Spec 1, page 1, middle of page 78 

"* Turn on Roll Engine *" through and including 

"EXTERN AL_D AT A.FRAMECOUNTER = INITIALIZATIONDATA.FRAMECOUNTER" : 
and 

" initialize SUBFRAME COUNTER * 

INITSUBFRAMECOUNTER = 1" 

Problem: All of the initialization of the global control store variables is to be performed by GCS_SIM, 
as stated in the Software Requirements document in Chaper 3. LEVEL 2 SPECIFIICATION. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

INIT GCS, P Spec 1, page 1, middle of page 79 

"* Turn on Roll Engine *" through and including 

"EXTERN AL_D AT A. FRAMECOUNTER = INITIALIZATIONDATA.FRAMECOUNTER" : 

Problem: These statements are not feasible because GUIDANCE STATE DATA and 
EXTERNAL DATA are group data flow names rather than control store names, so how can any data 
be copied? 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 
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AECLP, P-Spec 2.1 

AECLP, P-Specs 2.1.1 and 2.1.3 (AECLPEXPAND and AECLPCOMPRESS) 198 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group 
names to element names and back, which is not an actual function. Why would there be a P- Spec with 
no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

AECLP P-Spec 2.1.2, page 1 , TITLE 1 99 

"AECLP - Axial Engine Contrl Law Processing (P-Spec 2.3.1)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.1.2 which is 
the correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.3.1 
which is probably from the Software Requirements document. There needs to be some clarification 
here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

AECLP P-Spec 2. 1.2 212 

Top of Page 3: 

"real*8 theta" 

Middle and bottom of Page 4: 

"theta = ..." "PEINTEGRAL = PEINTEGRAL + theta * DELTAT" 

Top of Page 5: 

"theta = ..." "YEINTEGRAL = YEINTEGRAL + theta * DELTA T" 

Problem: According to the specification, THETA is a global data store variable in the 
GUIDANCE STATE data store. In FORTRAN, the same name cannot be used as a local variable. 

This is an implementation detail, but since it has entered the design, it is a problem. 

AECLP P-Spec 2.1.2, bottom of page 3 and top of page 4: 197 

"First: determine the axial engines' temperature (AE TEMP), as follows:.." 

Problem: It is not made clear which (if any) column in the table at the top of page 4 actually represents 
the new value for AE TEMP. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

AECLP P-Spec 2.1.2, pages 4-5 

Problem: There are instances where a global variable which has a time history subscript appears 
without any index for the time history. This leads to ambiguity. These instances are: 

1. Top of page 4, within table: 

"GP ALTITUDE <= ..." (occurs in two places) 200 

2. Middle of page 4: 

"if (GPVELOCITY(l) == 0)..." 

"..= GP VELOCIT Y (3 ) / GP_VELOCITY(l)" 

3. Page 5: 

"...= GP VELOCITY (2) / GP_VELOCITY(l)" 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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AECLP P-Spec 2.1.2, pages 4-5 20 1 

Middle of page 4: 

"theta = GP_VELOCITY(3) / GP_VELOCITY(l)" 

Top of page 5: 

"theta = GP VELOCITY (2) / GP_VELOCITY(l)" 

Problem: In each case for the denominator, the specification uses an absolute value, but the design 
doesn't. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

"Software Requirements Reference: AECLP, COMPUTE LIMITING ERROR FOR PITCH and 
COMPUTE LIMITING ERROR FOR YAW 

AECLP P-Spec 2. 1.2, 202 

Bottom of page 4 and middle of page 5: 

Problem: The calculation for limiting_pitch_error and limiting_yaw_error seem to impose a two-step 
implementation for no other reason than to avoid a continuation line. 

Question: Is there some other reason for this? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

AECLP P-Spec 2. 1 .2, top of page 6: 203 

Question: The possibility of a divide-by-zero can be avoided here if the design supplies a special 
solution for the differential equation for the case where OMEGA = 0. The specification does not, 
however, state this explicitly. Suggestion: perhaps modify the specification but do not cite a problem 
for the design now. 

AECLP P-Spec 2.1.2, pages 6-7 215 

Top of page 6: 

"if (AETEMP == cold or AETEMP == WARMINGJJP) 

te_limit_temp = 0. 

TELIMIT = 0. 

else if (AE TEMP == hot)" 

Middle of page 7: 

"end if* (AETEMP == ?) *" 

Problem: This conditional dealing with AE TEMP is added functionality because there is no such 
requirement in the specification. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

AECLP P-Spec 2. 1 .2, top of page 7 204 

"q_temp = -GAX(... * GP_ALTITUDE(1,3,0)...VELOCITY_ERROR 
+ GVEI(CL * TEINTEGRAL 

q_over_omega = ( GA * (q_temp + GVEI(CL) * TE INTEGRAL ) ) / OMEGA" 

Problem 1: In the equation for q_temp, the term "GP_ALTITUDE(1,3,0)" is incorrect. 

Problem 2: In the equation for q_temp, the parentheses are unbalanced, thereby making the equation 
ambiguous. 
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Problem 3 : After both of these equations are executed, the term q_over_omega will be 
incorrect because the term " GVEI(CL) * TEINTEGRAL" will have been added in twice. 
*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

AECLP P-Spec 2.1.2, top of page 7 211 

The design has not shown the derivation of the equation used to solve the differential equation 
for TELIMIT. 

AECLP P-Spec 2.1.2, bottom of page 7 216 

"pitcherror = 0. 
yawerror = 0. 
thrusterror = 0." 

Problem: These statements represent added functionality. In the case where AESWITCH is 
off, there is no requirement to set anything except AE CMD and AESTATUS, which is 
being done. In this case, pitch error, yaw error, and thrust error will not be used. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

AECLP, P-Spec 2.1.2, pages 3-7 214 

In the pseudocode, nested if s spanning many pages makes the logic extremely difficult to 
follow and may lead to an error-prone inspection. In this P-Spec, one nested if begins on page 
3, nests to a depth of four, and does not terminate until page 7. The problem is that it is very 
difficult to see the matching parts of each if block and therefore difficult to follow the logic. 

AECLP P-Spec 2. 1 .2, pages 7-9 205 

The variable TE LIMIT may be in error (depending on the actual values) when this P-Spec is 
finished executing because it will not include the processing that took place during the 
bounding process using TE MAX and TE MIN. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: AECLP, COMPUTE LIMITING 
ERROR FOR THRUST 

AECLP P-Spec 2. 1 .2, pages 7-8 206 

Problem: In each of four different places, an error message is given if the variable is outside 
its acceptable range. In three of the cases, the exception condition has already been handled 
in a previous place, and therefore this is added functionality. The places where this occurs 
are: 

Middle of page 7, "Give error message." (for AE SWITCH) 

Middle of page 8, "Give error message." (for CONTOUR CROSSED) 

Middle of page 8, "Give error message." (for CHUTERELEASED) 

Top of page 9, "Give error message." (for AESWITCH) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 
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AECLP P-Spec 2. 1 .2, top of page 9 207 

"else if (intcmd >= 0.0 & intcmd <= 1.0) AE_CMD(i) = 127 * intcmd" 

Problem: The specification states that "Each value for AECMD is to be rounded to the 
nearest integer, where rounding is defined...". The design does not show that the value for 
AE CMD is to be rounded. 

*Requirement: Fullfillment of requirements in Software Requirements document 
(References: DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: AECLP, COMPUTE AXIAL 
ENGINE VALVE SETTINGS. 

AECLP P-Spec 2. 1 .2, pages 3-9 209 

Limit Checking: 

1 . Bottom page 5 : 

The upper limit check for CONTOUR CROSSED is incorrect. 

2. Bottom page 6: 

"if (GP_ALTITUDE( 1,3,0) < ..." 

"else if (GP_ALTITUDE(1,3,0) > ..." 

Problem: GP ALTITUDE only has one dimension, but the design uses three. 

4. The following input variables to this P-Spec are not checked at all for limit violations: 

GP ATTITUDE, CL, GP VELOCITY 

5. The following output variables to this P-Spec are not checked at all for limit violations: 

AE CMD, AE STATUS 

AECLP P-Spec 2.1.2, pages 3-9 217 

Problem: The fact that most of the limit checking is done inside nested if-then statements 
seriously obscures the flow of control of the P-Spec, and makes it difficult to check if limit 
checking has been done correctly. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

AECLP P-Spec 2.1.2, bottom page 8, and top page 9 210 

"intcmd = INTERNAL_CMD(I)" 

"if (int cmd < ..." 

"else if (int cmd > 1.7..." etc. etc. 

Problem: The use of the local variable int cmd seems to serve no function and introduces 
added complexity. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 
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ARSP, P-Spec 2.2.2 

ARSP P-Specs 2.2.1 and 2.2.3 (ARSPEXPAND and ARSPCOMPRESS) 19 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group names to 
element names and back, which is not an actual function. Why would there be a P- Spec with no body? 
*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

ARSP P-Spec 2.2.2, page 1, TITLE 21 

"ARSP - Altimeter Radar Sensor Processing (P-Spec 2.1.2)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.2.2 which is the 
correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.1.2 which 
is probably from the Software Requirements document. There needs to be some clarification here. 
*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

ARSP P-Spec 2.2.2, page 1, bottom of page: 20 

"Shift Data in ARALTITUDE, ARSTATUS..." 

Problem: More detail is needed. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Translatability to source code (Reference: Software Development Standards, 

Software Design Standards, "The low level requirements should be directly translatable into 
source code, with no further decomposition required.") 

ARSP P-Spec 2.2.2, page 2, top of page: 22 

"if (FRAMECOUNTER == even) 

AR ALTITUDE. * = AR ALTITUDE. [previous value] 

ARSTATUS.* = ARSTATUS. [previous value] 

KALT.* = KALT. [previous value]" 

Problem: The step before this in the design was to rotate these same variables unconditionally. These 
three assignments will cause a second rotation, which is incorrect. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: ARSP, Rotate Variables 

ARSP P-Spec 2.2.2, page 2, top of page: 23 

" ARALTITUDE. * = ARALTITUDE. [previous value] 

AR STATUS.* = AR STATUS. [previous value] 

K ALT.* = K ALT. [previous value]" 

Problem: The notation ".*" is confusing here. Pages 6 and 7 of the design says this refers to 
independent iteration over 3 axes, or to three independent axes, but there are no axes involved here. It 
seems what is intended is rotation, but this rotation is ambiguous. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 

6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: ARSP, Rotate Variables 
*Requirement: Translatability to source code (Reference: Software Development Standards, Software 
Design Standards, "The low level requirements should be directly translatable into source code, with 
no further decomposition required.") 
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ARSP P-Spec 2.2.2, page 2, top of page: 121 

" ARALTITUDE. * = ARALTITUDE. [previous value] 

ARSTATUS.* = ARSTATUS. [previous value] 

KALT.* = KALT. [previous value]" 

Problem: The notation ".[previous value]" has not been explained prior to its use. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

ARSP P-Spec 2.2.2, page 2, middle of page: 134 

Limit checks for AR ALTITUDE, AR STATUS, and K ALT: 

Problem 1: In each case, the notation is used; however in each case, the element is a scalar, except 
for the time history. Are all elements of the time history to be checked? (Note that on the page 3 limit 
check, only AR_ALTITUDE.[0] is checked (which is correct)). 

Problem 2: The rotations have been done, but the new values have not been calculated, so which history 
value is being checked? 

ARSP P-Spec 2.2.2, page 3, top of page: 24 

"if (ARFREQUENCY == 0)..." 

Problem: AR FREQUENCY does not contain zero in its valid range. 

Problem: In the case where an echo is not received, AR FREQUENCY is not used, but this check is 
made whether or not an echo is received. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: ARSP, Determine Altitude 
*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

ARSP P-Spec 2.2.2, page 3, top of page: 25 

"AR_ALTITUDE.[0] = (AR COUNTER * 3 * 10**8 ) / AR FREQUENCY * 2 " 

Problem: In the overview meeting, the designer stated that the syntax for the pseudocode was 
FORTRAN 77. If that is the case, then, due to the hierarchy of operations in FORTRAN, " / 

AR FREQUENCY * 2 " means that AR FREQUENCY is part of the numerator, which is incorrect. 
*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: ARSP, Determine altitude if echo received 

ARSP P-Spec 2.2.2, page 3, top of page: 26 

Problem: A lower limit check is made for AR ALTITUDE(O), but the upper limit check is not made. 
*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, Upper 
Limit Exceeded 
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ARSP P-Spec 2.2.2, page 3, middle of the page 15 

Starts with "Construct a table of divided differences....": 

"1. The first column of the table holds the four previous altitudes." 

Problem: The design does not state the specific order for the four previous altitudes, that is, is the 
entry in the first row the most recent or the oldest altitude? This order must be stated because it 
will affect the result. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 

DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: ARSP, Determine Altitude if all 
previous values of ARSTATUS are healthy, by fitting a polynomial and then evaluating it. 

ARSP P-Spec 2.2.2, page 3, middle of the page 105 

Starts with "Construct a table of divided differences....": 

"2. The 2nd column holds the differences between..." 

Problem: The design does not state the order for the subtraction, i.e., is it: 
diff= element in row i - element in row i+1, or 
diff = element in row i+1 - element in row i? 

The order must be stated because it will affect the result. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 

DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: ARSP, Determine Altitude if all 
previous values of AR STATUS are healthy, by fitting a polynomial and then evaluating it. 

ARSP P-Spec 2.2.2, page 3, middle of the page 106 

Starts with "Construct a table of divided differences....": 

Question: 

Is it possible to give a reference for this method? 1 have found several texts which present this 
method, but only show the equation for the coefficients of the interpolating polynomial. The step 
which is missing is going from the polynomial to the direct evaluation at the current point by 
doing the summation. I have convinced myself that the resulting evaluation is exactly equivalent 
to the Lagrange method, and therefore am convinced this method is correct, but would like to see 
the reference text or the derivation, if possible. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 

DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: ARSP, Determine Altitude if all 
previous values of AR STATUS are healthy, by fitting a polynomial and then evaluating it. 

ARSP P-Spec 2.2.2, page 4, middle of page: 27 

"ARALTITUDE.* = ARALTITUDE. [previous value]" 

Problem: The notation is used here but there are no axes involved. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

ARSP P-SPEC 2.2.2 82 

The variables AR STATUS and K ALT are checked for limits exceeded in the case where 
FRAMECOUNTER is even, but they are not checked for limits exceeded in the case where 
FRAME COUNTER is odd. 
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ASP, P-Spec 2.3.2 

ASP, P-Specs 2.3.1 and 2.3.3 (ASPEXPAND and ASPCOMPRESS) 148 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group 
names to element names and back, which is not an actual function. Why would there be a P- Spec with 
no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

ASP P-Spec 2.3.2, page 1, TITLE 153 

"ASP - Accelerometer Sensor Processing (P-Spec 2.1.1)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.3.2 which is 
the correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.1.1 
which is probably from the Software Requirements document. There needs to be some clarification 
here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

ASP P-Spec 2.3.2, page 2, middle of page: 149 

"Shift Data the AACCELERATION.* AND..." 

Problem 1: More detail is needed. 

Problem 2: ".*" notation 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Translatability to source code (Reference: Software Development Standards, Software 
Design Standards, "The low level requirements should be directly translatable into source code, with 
no further decomposition required.") 

ASP P-Spec 2.3.2, page 1, bottom of page: 156 

"BEGIN LOCAL TYPE DEFS 
real a_gain.* 


real hold 

END LOCAL TYPE DEFS" 

Question: Is there any special significance here when "real" is used, while most other P-Specs use 
"real*8" or "real*4"? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

ASP P-Spec 2.3.2, pages 1-3 157 

Problem: The "*." notation used throughout the entire P-Spec is very confusing and ambiguous. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

ASP P-Spec 2.3.2, pages 1 and 2 158 

"real at" 

"at = "ATMOSPHERICTEMP" 

Question: What is the purpose for this step? It doesn't seem to accomplish anything. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 
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ASP P-Spec 2.3.2, page 3, top of page 159 

"accel.* = ALPHAMATRIX.*.* * accel.*" 

Problem: This is supposed to be a matrix multiplication, but as stated here it appears to be a 
scalar multiplication. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

*Software Requirements Document, ASP, CORRECT FOR MISALIGNMENT 

ASP P-Spec 2.3.2, page 3 160 

"if [A_STATUS.*.[all 1..3]..." 

Problem: The notation ".[all 1..4] is explained but not ".[all 1..3]" 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

ASP P-Spec 2.3.2 161 

Question: This P-Spec does not provide special handling for the case where all three values 
of AACCELERATION are exactly equal, in order to avoid roundoff and a possible negative 
square root error later in the standard deviation. I don't really believe this is required, but it 
was brought up in a previous meeting of the GCS team. 

ASP P-Spec 2.3.2 163 

The variable A ACCELERATION has not been checked for limits exceeded. 

**Software Requirements 2.2 with Mods 1-26 Reference: 
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CP, P-Spec 2.4 

CP, P-Specs 2.4. 1 and 2.4.3 (CPEXPAND and CPCOMPRESS) 230 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group 
names to element names and back, which is not an actual function. Why would there be a P- Spec with 
no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

CP P-Spec 2.4.2, page 1 , TITLE 23 1 

"CP - Communications Processing (P-Spec 2.4)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.4.2 which is 
the correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.4 
which is probably from the Software Requirements document. There needs to be some clarification 
here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

CP P-Spec 2.4.2 232 

INPUT/OUTPUT Section: 

1 . The control flows ITH FRAME 2 and ITHFRAME5 which are shown on the CP DFD/CFD 
diagram and which are used as inputs to this P-Spec, are missing from the INPUT/OUTPUT section. 

2. The data flows NBYTES and BYTEPACKET both of which appear on the CP DFD/CFD as 
outputs from CP to CALCULATE CRC-16, are missing from the INPUT/OUTPUT section. 

3. The data flow CHECKSUM which appears on the CP DFD/CFD as an input to CP from 
CALCULATE CRC-16 is missing from the INPUT/OUTPUT section. *Requirement:Completeness 
(Reference: DO-178B 11.0b) 

CP P-Spec 2.4.2 249 

See #56 in DATA DICTIONARY problems for BYTE PACKET. 

CP P-Spec 2.4.2, page 3 259 

Definitions for init_sample_mask_sub_fr_l and 2 and 3: 

Problem: Since the notation "B'...' " is not FORTRAN notation, it is ambiguous. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

CP P-Spec 2.4.2, bottom half of page 3 and top half of page 4 240 

This table which unfortunately spans two pages and shows the variable names vertically is in such a 
format that it is virtually impossible to read and interpret, and some variables (eg. GP ROTATION 
and KMATRIX) are missing. This table is important and should be presented in an easily 
understandable format, eg, horizontally. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

CP P-Spec 2.4.2, bottom page 4 243 

"Set bits for AR ALTITUDE... every other frame:" 

1 . The variables K ALT and K MATRIX are missing from this list. 
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CP P-Spec 2.4.2, bottom page 4 

1. Bottom of page 4: 244 

"Starting with byte eight, load BYTEPACKET alphabetically with (subframe 1 variables, 

AR ALTITUDE,. ..TS STATU S). " . . .TDLRVELOCITY, and TSSTATUS)." 

2. Top of page 5: "Starting with byte eight, load ...TDSSTATUS and TDSENSED)." 

3. Middle of page 5: "Starting with byte eight... sub frame 1 variables, and...TS_STATUS)." 

4. Bottom of page 5: "Starting.. .with subframe 1 data:...G_STATUS." 

Problem: In each one of these cases for subframe 1, the design is attempting to state which 
variables must be loaded into the data section of the packet. 

1 . There is some ambiguity in the statement of exactly which variables are to be loaded. 

There is a comment above describing "Subframe one's variables", but this is merely a 
comment and not a strict definition (see #250) as part of the design. In addition the 
statement of which variables to load(except for #4 above) does not include the word 
"and" or any synonym for "and", and thus one could be misled into thinking that the 
variables listed in the load statement are the only variables to be loaded, which would be 
incorrect. 

2. #4 above uses the term "subframe 1 data" which in this case actually means the 
variable names that follow, which lends to even more confusion. 

3. It would be significantly more clear if for each case, the design would state 
alphabetically in one list all the variables to be loaded for that case. 

CP P-Spec 2.4.2, bottom page 4 

1. Top of page 6: 252 

"Starting with byte eight, load BYTE PACKET alphabetically with subframe two's 
data." 

Problem: For subframe 2, the design is attempting to state which variables must be 
loaded into the data section of the packet. There is some ambiguity in the statement of 
exactly which variables are to be loaded. There is a comment above describing 
"Subframe two's data", but this is merely a comment and not a strict definition (see 
#250) as part of the design. 

CP P-Spec 2.4.2, bottom page 4 253 

1. Bottom of page 6: 

"Starting with byte eight, load BYTE PACKET alphabetically with (subframe three's 
variables and CHUTE RELEASED)." "Starting with byte eight, load BYTE PACKET 
alphabetically with subframe three's variables." 

Problem: For subframe 3, the design is attempting to state which variables must be 
loaded into the data section of the packet. There is some ambiguity in the statement of 
exactly which variables are to be loaded. There is a comment above describing 
"Subframe three's variables ", but this is merely a comment and not a strict definition 
(see #250) as part of the design. It would be significantly more clear if for each case, the 
design would state alphabetically in one list all the variables to be loaded for that case. 
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CP P-Spec 2.4.2, pages 4 - 6: 242 

The terms "first", "lowest", and "last" are used in many places, but are ambiguous. More specific 
wording is needed. Some examples of occurrences are: 

Top of page 4: "Load the MSB of COMMSYNCPATTERN first." 

Top of page 4: "Load the lowest 8 bits..." 

Bottom of page 4: "Copy samplemask's LSB first and its MSB last. 

Bottom of page 4: "their MSB first and their LSB last." 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

CP P-Spec 2.4.2, pages 4 - 6 250 

1. Middle of page 4: "* Subframe one's variables consist... values described *" 

2. Bottom of page 5 to top of page 6: "Subframe two's data...VELOQTY_ERROR" 

3. Middle of page 6: "Subframe three's variable's ...YEINTEGRAL" 

Problem: All of the above are formatted as comments but in reality apparently were actually 
intended to be part of the design. See Problem # 244. 

CP P-Spec 2.4.2, middle of page 5 : 251 

"Set bits 3, 5, 6, 7. ..28, and 29...sample_mask." 

Problem: The bits for K ALT and K MATRIX are missing. 

CP P-Spec 2.4.2, pages 4 - 6 255 

"if (sub lfame counter == 1)" 

"else if (sub_frame_counter == 2)" 

"else if (sub_frame_counter == 3)" 

Problem: The variable name "sub frame counter" is not correct. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

CP P-Spec 2.4.2, bottom page 4 through bottom of page 6 245 

"Set NBYTES with the total number of bytes stored in BYTEPACKET." 

Problem: The statement above occurs seven times. In each case, the design has not provided the 
actual number of bytes, nor has it provided an algorithm for obtaining this number. 

*Requirement: Translatability to source code (Reference: Software Development Standards, 

Software Design Standards, "The low level requirements should be directly translatable into 
source code, with no further decomposition required.") 

CP P-Spec 2.4.2, page 7, and DFD/CFD for CP. 256 

"call CALCULATE CRC-16... CHECKSUM)" 

Problem: The issue of one P-Spec calling another and how this is to be treated on the DFD/CFD at this 
point is unresolved. 

CP P-Spec 2.4.2, page 7 257 

"Store lower 16 bits of CHECKSUM in BYTE PACKET in locations NBYTES+1 AND NBYTES+2" 

Problem 1: Since CHECKSUM is only 16 bits, why the statement "lower 16 bits"? 

Problem 2: In what order are the two bytes to be stored? 
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CP P-Spec 2.4.2, page 7 258 

"Set C STATUS to healthy" 

Problem: This step must be done at any point prior to calculating the CHECKSUM and prior to loading 
C_STATUS into BYTEPACKET and PACKET. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

** Software Requirements 2.2 with Mods 1-26 Reference: CP, SET COMMUNICATOR STATUS TO 
HEALTHY." 

CP P-Spec 2.4.2, top of page 7 254 

"Give error '(CP. ..value" 

Problem: This represents added functionality. There is no requirement for checking the 
limits on SUBFRAME COUNTER because it is in EXTERNAL data store. 

CP P-Spec 2.4.2 246 

General: 

There are several places in this P-Spec where the variables KMATRIX and/or GPROTATION are 
loaded into the packet, but nowhere is it stated that the constant terms (the off-diagonal elements of 
K MATRIX and the diagonal elements of GP ROTATION) should not be loaded. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: CP, PREPARE DATA SECTION. 

CP P-Spec 2.4.2 247 

General: 

The design has not stated that only current history variables should be loaded into the packet. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: CP, PREPARE SAMPLE MASK 

CP P-Spec 2.4.2 248 

General: 

For each particular unique mask and packet, the design needs to explain how it was derived, i.e., 
specifically which modules are executing for that case. 

. CP, P-Spec 2.4.2 266 

General: 

No limit checking is done in this P-Spec, which actually is as it should be; however it might 
be a good idea to modify the specification to explicitly state this. 

. CALCULATE CRC- 16, P-Spec 2.4.5, bottom page 1 261 

"For each of the 16 integer*4 entries in the table, store the zero-origin index (0 throught 15) into a 
temporary variable." 

Problem: The intent here is that all the steps beginning with "store the zero-origin index..." through 
and including "When 1) through 3). ..(table index)." be done for each of the 16 integer*4 entries in the 
table; however what has been stated is that only the very first step be done for all 16 entries. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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CALCULATE CRC-16, P-Spec 2.4.5, bottom page 1 262 

Bottom of page 1: "2. "Logically shift the temporary variable. ..right." 

Middle of page 2: "2. Shift the ere right four bits, using a logical shift." 

Problem: The terms "logically shift" and "shift.. .using a logical shift" should be precisely 
defined. Specifically, what rule is used to fill in the bits vacated on the left? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

. CALCULATE CRC-16, P-Spec 2.4.5, middle page 2 263 

"1. Exclusive-or the first byte in BYTEPACKET into the lower eight bits of the ere." 

Problem 1 : "first" is not an accurate description of which byte is to be used on any except the 
first iteration. 

Problem 2: This sentence does not state with what data the byte in BYTE PACKET is to be 
exclusive-ored. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

. CALCULATE CRC-16, P-Spec 2.4.5, middle page 2 264 

"3. Using the four bits. ..Exclusive-or the indexed table entry with the results of the shifted 
ere." 

Problem: Thi s sentence does not state where the new exclusive-ored value is to be placed. 
*Requirement: Completeness (Reference: DO-178B 11.0b) 

. CALCULATE CRC-16, P-Spec 2.4.5 265 

The design should provide either a derivation or a reference to the derivation of the 
algorithms used to create the table and then to use the table to calculate the ere. 


CRCP, P-Spec 2.5 

CRCP, P-Specs 2.5.1 and 2.5.3 (CRCP EXPAND and CRCP COMPRESS) 193 

These P-Specs do not appear to have any useful function. A P-Spec should perform some 
function that converts its input elements to its outputs. These P-Specs seem to convert from 
control flow group names to element names and back, which is not an actual function. Why 
would there be a P- Spec with no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

CRCP P-Spec 2.5.2, page 1, TITLE 194 

"CRCP - Chute Release Control Processing(P-Spec 2.3.3)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.5.2 
which is the correct P-Spec number for this design. The title, on the other hand, contains P- 
Spec number 2.3.3 which is probably from the Software Requirements document. There 
needs to be some clarification here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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GSP, P-Spec 2.6.2 

GSP, P-Specs 2.6.1 and 2.6.3 (GSP_EXPAND and GSP_COMPRESS) 140 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group 
names to element names and back, which is not an actual function. Why would there be a P- Spec with 
no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

GSP P-Spec 2.10.2, page 1, TITLE 151 

"GSP - Gyroscope Sensor Processing (P-Spec 2.1.4)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.6.2 which is the 
correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.1.4 which 
is probably from the Software Requirements document. There needs to be some clarification here. 
*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

GSP P-Spec 2.10.2, page 1 155 

"real*4 at 
real*4 g_gain.* 

Problem: Precision will be lost because of the data type "real*4". Requirement: ??? 

GSP P-Spec 2.6.2, page 2, top of page: 145 

"Shift Data in G_ROTATION..." 

Problem: More detail is needed. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Translatability to source code (Reference: Software Development Standards, Software 
Design Standards, "The low level requirements should be directly translatable into source code, with 
no further decomposition required.") 

GSP, P-Spec 2.6.2 146 

page 1: 

"real*4 g_gain.*" 

"real*4 count.*" 
page 2: 

" g g ain.* = ..." through "write (6,99) "GROT ATION . * GROTATION.*" 

The ".*" notation is ambiguous. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

GSP, P-Spec 2.6.2, page 1 and page 2, middle and end of page 147 

"real*4 at" 

"at = "ATMOSPHERICTEMP" 

Question: What is the purpose for this step? It doesn't seem to accomplish anything. 

GSP, P-Spec 2.6.2 162 

The variable G STATUS (in GUIDANCE_STATE) has not been checked for limits exceeded. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, Upper or 
Lower Limit Exceeded 
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GP, P-Spec 2.7 

GP, P-Specs 2.7.1 and 2.7.3 (GPEXPAND and GPCOMPRESS) 170 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group 
names to element names and back, which is not an actual function. Why would there be a P- Spec with 
no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 

6.3.2a, and 11. Of) 

GP P-Spec 2.7.2, page 1, TITLE 171 

"GP - Guidance Processing (P-Spec 2.2)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.7.2 which is 
the correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.2 
which is probably from the Software Requirements document. There needs to be some clarification 
here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

GP, P-Spec 2.7.2, pages 1-2, INPUT/OUTPUT section. 180 

The variable END_GCS which is an output has been omitted from this section. 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

GP, P-Spec 2.7.2, page 2, bottom of page: 173 

"BEGIN LOCAL TYPE DEFS 
real interpolated velocity 

real new_gp_atti tude.*.* 

END LOCAL TYPE DEFS" 

Problem: Precision may be lost if real (default real*4) is used. 

GP, P-Spec 2.7.2, page 3, middle of page: 172 

"Shift Data in the GP VELOCITY... during this time step 
Problem: More detail is needed. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Translatability to source code (Reference: Software Development Standards, Software 
Design Standards, "The low level requirements should be directly translatable into source code, with 
no further decomposition required.") 

GP, P-Spec 2.7.2, Notation Problems: 174 

Pages 2 and 3: The ".*" and ".*.*" notation throughout these pages is ambiguous. 

Page 8, middle of page: 

" GPVELOCIT Y. [ 1 ] . . . " 

Pages 9-11: 

"alpha. [n], beta.[n], correction termfn]", where n = 0 or 1 or 2, are ambiguous. 

Pages 2-11: 

It is not always clear what is a comment and what is pseudocode. Also there are random "*" in some 
of the comments. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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GP, P-Spec 2.7.2, page 3: 175 

"Calculate new attitude.*.*" through "Calculate new altitude:..." 

This design calculates completely all the attitude values, then calculates completely all the 
velocity values, and then calculates completely all the altitude values. The specification says 
to calculate all three (attitude, velocity, and altitude) simultaneously. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

*Software Requirements Document Reference: APPENDIX C, first paragraph, "If the Runge- 
Kutte method is used, it is required that the three equations be solved as a set of simultaneous 
equations. 

GP, P-Spec 2.7.2, pages 3 and 9: 176 

Problem: The set up of the GPROTATION MATRIX is not handled properly. 

The only information given regarding the GP ROTATION matrix is given at the top of page 9. 

This is neither a correct nor a sufficient explanation for setting up or for the use of the matrix. 

The specification states that one should "...use a temporary variable during calculation to hold 
the time histores of GP ROTATION or to use elements directly from GROTATION; 
however, GP ROTATION does describe. ..should contain the correct values for the present 
time step." All of this statement is being violated by this design. In addition, the correct setup 
must be done during or before the Runge-Kutte method is executed (on page 3) 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

*Software Requirements Document Reference: GP, SET UP THE GP ROTATION MATRIX. 

GP, P-Spec 2.7.2 181 

Limit Checking, pages 4 - 8 

1. The lower limit used for GPALTITUDE is incorrect. 

2. The lower limit used for FRAMEENGINESIGNITED is incorrect. 

3. There is no limit check for the upper bound on AETEMP. 

4. The following input/output variables to this P-Spec are not checked at all for limit 
violations: 

GP ATTITUDE, A ACCELERATION, K ALT, AE SWITCH, AR ALTITUDE, 

CONTOUR CROSSESD, G ROTATION, K MATRIX, RE SWITCH, 

VELO CIT Y ERROR, TE INTEGRAL, GP ROTATION 

5. The following variables are only checked for one case, namely the case where 

GPPHASE = 1, and GP ALTITUDE <= ENGINESONALTITUDE: 

FRAME ENGINES IGNITED, AE TEMP, BHUTE RELEASED, TDS STATUS, 

GP VELOCITY, TD SENSED 
*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

GP, P-Spec 2.7.2, page 4, bottom 178 

"if (GP PHASE = one and GP ALTITUDE [tno w] <= ENGINES ON ALTITUDE" 

The term "tnow" has not been defined or explained. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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* GP, P-Spec 2.7.2, page 4, bottom through page 7,top 179 

Algorithm for determining GP_PHASE, AE SWITCH, RE SWITCH, FRAMEENGINESIGNITED, 
and ENDGCS: 

Begins "if (GP_PHASE==one", ends with "end if' 

Note on Notation: Let SQT represent sqrt (2 x GRAVITY X GPALTITUDE) + x component of 
GPVELOCITY 

Problems: 

1. "hold = (2*GRAVITY*GP_ALTITUDE+GP_VELOCITY.[l])" "result = 
sqrt(2 *GRAVIT Y*GP_ALTITUDE+GP_VELOCIT Y. [ 1 ])" 

Problem: Both of these statements incorrectly include the term "+GP_VELOCITY.[l]" 

2. The case where GP_PHASE = 2 and AE TEMP = hot and TDS_STATUS = healthy should not be 
setting GPPHASE to 5. (line 3) 

3. The case GP_PHASE = 3 and GP ALTITUDE <= DROPHEIGHT and TDS_STATUS is healthy 
should not be setting GP PHASE to 4 or turning off engines without checking SQT and 
TDSENSED. (line 4) 

4. The two places under GP PHASE == three that have the conditional: "else if (GP ALTITUDE 

== DROP HEIGHT and TDS_STATUS = failed" 

Problem 1 : There is no reason to make of special case for GP ALTITUDE exactly equal to 
DROP HEIGHT since the specification doesn't make it a special case. 

Problem 2: Control will never reach the second conditional, and so it will never be executed. There 
is a contradiction in that these are the same conditionals yet call for two different types of 
processing to take place. 

Problem 3 : It is not clear if control can ever reach the first conditional because it is actually a subset 
of the conditional that is executed before it, namely: 

"else if (GP ALTITUDE <= DROP HEIGHT and TDS_STATUS == failed" 

Problem 4: Under the second conditional is another contradiction. It contains the conditional: 

"if (result <= MAX N ORMAL VELOCIT Y and TDS_STATUS == healthy" 

Control would never have reached here unless TDSSTATUS were failed, so this conditional can 
never be true. 

5. The case where GP_PHASE = 3 and GP ALTITUDE = DROP HEIGHT, is not turning the 
engines off or setting END GCS to TRUE. In fact, this case has already been treated correctly for 
GP ALTITUDE <= DROP HEIGHT and did not need to be handled again, (line 7) 

6. The case where GP_PHASE=4 and TDS_STATUS = healthy and TD SENSED is not sensed, 
should not be setting END GCS to TRUE, (line 12) 

7. At the top of page 7, " else (GP PHASE == ? )" is ambiguous, (line 13) 

8. Middle of page 6: 

"GPSTATUS = five" 

GPSTATUS is not a defined variable, (line 7) 

9. The terms GP ALTITUDE and GP VELOCITY are used many time throughout these pages 
without any subscripts. This is ambiguous. 

10. Middle of page 6: 

"result = . . GPVELOCIT Y. [ 1 ] " 

This notation is not clear., 

11. "and TDS STATUS = failed" 

All other places use "==". Is this a typo, or does it have a different meaning. 
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Conclusions: This design has attempted to include the processing for Tables 5.9 and 5.10 into one large 
multi-page nested if-then-elseif statement. The merging of the two tables, and the many errors and 
inconsistencies make the design very confusing and very difficult to understand. The approach is so 
complicated, and there are enough errors in the control-handling logic, that it is impossible at this stage 
of the review to be certain that all the cases have been handled correctly. In fact, it seems that it would 
not be feasible to modify/maintain this particular design with an acceptable degree of accuracy. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

GP, P-Spec 2.7.2, middle page 7 182 

"This process would normally be done only once at initialization time;" 

Question: what does this mean? 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

GP, P-Spec 2.7.2, middle page 7 184 

"This process would normally be done... 

Search the CONTOURVELOCITY array for a zero value... index value. ..while accessing the zero 
value." 

Problem 1: "Search the CONTOUR VELOCITY array for a zero value..." 

Problem: The variable name here is incorrect. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

Problem 2: The comments do not state explicitly of what we are attempting to find the size. 

Problem 3 : It is not impossible to determine the algorithm implied here, 
but the language used is imprecise and could lead to ambiguity. It is not 
an algorithmic solution. 

Problem 4: "If off end of array, set size. ..if zero value is found, set size..." 

Problem: There is no local variable named "size". In addition, there is no place in the 
pseudocode where "size" is explicitly used. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 

6.3.2a, and 11. Of) 

GP, P-Spec 2.7.2, middle page 7 186 

"if (GP ALTITUDE <= EN GINES ON ALTITUDE) " 

Problem: According to the specification, the determination of the VELOCITY ERROR is 
unconditional: therefore, this conditional is incorrect and introduces additional functionality. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

GP, P-Spec 2.7.2, middle page 7 187 

"Do a binary search in the. ..spurious results in his case." 

Problem: The procedures for doing a binary search, interpolation and 
extrapolation are not explained in sufficient detail to represent an 
actual algorithmic solution. 

*Requirement: Translatability to source code (Reference: Software 

Development Standards, Software Design Standards, "The low level requirements should be 
directly translatable into source code, with no further decomposition required.") 
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GP, P-Spec 2.7.2, bottom page 7 188 

"hold = ((GP VELOCITY.x ) A 2 + ... - interpolated velocity" 

Problem 1 : The specification states to use the x component of GPVELOCITY. The design is using the 
magnitude of GP_VELOCITY. 

Problem 2: The design is checking for an exceptional condition on a term which is not really the 
argument of the square root, (this problem may go away when problem 1 is fixed.) 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

*Software Requirements Reference: GP, DETERMINE VELOCITY ERROR 

GP, P-Spec 2.7.2, top page 8 189 

"if GPALTITUDE <= EN GINES ON ALTITUDE 
and 

VELOCITYERROR > 0 ..." 

Problem: The relational operator ">" in the phrase VELOCITY ERROR > 0" is incorrect. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

* Software Requirements Reference: GP, DETERMINE IF CONTOUR HAS BEEN CROSSED 

GP, P-Spec 2.7.2, middle page 8 192 

"if (CL = first and optimalvelocity == ..." 

Problem: The term "optimal velocity" is not defined nor explained in this design and is therefore 
ambiguous. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

GP, P-Spec 2.7.2, top page 9 190 

"...the definitions of these terms given in section 2.7 GP..." 

Problem: GP is no longer section 2.7 in the specification. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

GP, P-Spec 2.7.2, bottom of page 8 through end of page 11 191 

"NOTES:..." 

Problem 2: The equations given for the derivatives do not provide sufficient detail to be translatable 
into code. Thelndividual matrix equation for the derivative of each of attitude, velocity, and altitude, 
should be explicity given. In each equation, it should be made completely clear which time history 
value or calculated value should be used for any of the three variables GP ATTITUDE, 

GP VELOCITY, and/or GP ALTITUDE, as well as which time history values should be used for the 
sensor variables (G ROTATION, A ACCELERATION, K MATRIX, TDLR VELOCITY, K ALT, 
and/or AR ALTITUDE) which appear in that particular equation. The derivative equations being 
referenced here are: 
d/dt(Vbl.[2]) 
d/dt( Vbl. [ 1 ]est_A) 
d/dt(Vbl.[l]est_B) 
d/dt(Vbl.[0]est_C) 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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RECLP, P-Spec 2.8 

RECLP, P-Specs 2.8. 1 and 2.8.3 (RECLPEXPAND and RECLP COMPRESS) 226 

These P-Specs do not appear to have any useful function. A P-Spec should perform some 
function that converts its input elements to its outputs. These P-Specs seem to convert from 
control flow group names to element names and back, which is not an actual function. Why 
would there be a P- Spec with no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 

6.3.2a, and 1 1 .Of) 

RECLP P-Spec 2.8.2, page 1, TITLE 227 

"RECLP - Roll Engine Contrl Law Processing (P-Spec 2.3.2)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.8.2 
which is the correct P-Spec number for this design. The title, on the other hand, contains P- 
Spec number 2.3.2 which is probably from the Software Requirements document. There 
needs to be some clarification here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

RECLP P-Spec 2.8.2 220 

Middle of page 2: "if (GROTATION.x < -1" 

Bottom of page 2: "xrollrate = G ROTATION.x" 

Problem: The variable G ROTATION is a history variable, but no history subscript is 
indicated here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

RECLP P-Spec 2.8.2, bottom of page 2 224 

"if (THETA < PI)" 

"else if (THETA > PI)" 

Problem: No definition has been given for "PI". 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

RECLP P-Spec 2.8.2 225 

Limit Checking 

1. Bottom page 2: 

The lower and upper limit checks for THETA taken together imply that THETA must be 
exactly equal to some number PI, which is not correct according to the Data Dictionary of the 
specification. 

2. Limit checks are missing for the following output variables: RE CMD, RE STATUS, THETA 
*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

RECLP P-Spec 2.8.2, bottom of page 2 221 

"* Determine which region of the graph (Figure 5. 10 pg 60 of spec..." 

Problem: Neither the Figure Number nor the page number is correct. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 
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RECLP P-Spec 2.8.2, bottom of page 2 and top of page 3 222 

"Use "if' statments constructed using... command should be used." 

Problem: This description of how to find the correct region is inadequate and does not 
provide enough detail to be an algorithmic solution which can be translated to code. There is 
nothing in this description to even indicate which variables (other than the 
RUNPARAMETER variables) are involved in finding the region nor how they are to be 
used. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Translatability to source code (Reference: Software 

Development Standards, Software Design Standards, "The low level requirements should be 
directly translatable into source code, with no further decomposition required.") 

RECLP P-Spec 2.8.2, page 3 223 

Problem: The term "lowest bit(s)" is used in three different places. It needs a precise 
definition. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

RECLP P-Spec 2.8.2, middle of page 3 219 

"Give error message." 

The variable RE SWITCH has already been checked and handled properly for values 
outside its acceptable range. This error message represents added functionality which 
cannot be traced to the specification. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 
11. Of) 
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TDLRSP, P-Spec 2.9.2 


TDLRSP DFD 28 

TDLRSTATUS appears as an input to P-Spec 2.9.2. It is not an input to TDLRSP. (also see #94) (SEE 
FORMAL MODIFICATION 2.2-16.2) 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

TDLRSP P-Specs 2.9.1 and 2.9.3(TDLRSP_EXPAND and TDLRSPCOMPRESS) 29 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group 
names to element names and back, which is not an actual function. Why would there be a P- Spec with 
no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

TDLRSP P-Spec 2.9.2, page 1, TITLE 107 

"TDLRSP - Touch Down Lander Radar Sensor Processing (P-Spec 2.1.3)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.9.2 which is 
the correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.1.3 
which is probably from the Software Requirements document. There needs to be some clarification 
here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TDLRSP P-Spec 2.9.2, page 2, TOP of page: 30 

"Shift the data in the FIFOS: TDLRVELOCITY.#..." 

Problem: More detail is needed. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: TDLRSP, Rotate Variables 
*Requirement: Translatability to source code (Reference: Software Development Standards, Software 
Design Standards, "The low level requirements should be directly translatable into source code, with 
no further decomposition required.") 

TDLRSP P-Spec 2.9.2, page 2 128 

"if (TDLRVELOCITY.x < -100)" 

"else if (TDLR VELOCITY.x > 100)" 

Problem 1 : It is not clear exactly what the notation ".x" means (see #122). If it refers to just the first 
element, why is an additional check being made for all elements at the bottom of page 4? 

Problem 2: It is not clear which elements in the time history are being checked. If the most recent are 
implied, then there is a problem because the rotation has already taken place but the new element has 
not yet been calculated.. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, Upper or 
Lower Limit Exceeded 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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TDLRSP P-Spec 2.9.2, page 2 129 

"if (K_MATRIX.*<0)" 

"else if (KMATIX.* > 1)" 

Problem 1: KMATRIX has three dimensions. It's not clear here which dimensions are being checked. 

Problem 2: It is not clear which elements in the time history are being checked. If the most recent are 
implied, then there is a problem because the rotation has already taken place but the new elements have 
not yet been calculated. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, Upper or 
Lower Limit Exceeded 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TDLRSP P-Spec 2.9.2, page 2, MIDDLE of page: 3 1 

"if (FRAMECOUNTER == even) 

set TDLRVELOCITY. * to previous value of TDLR VELOCITY.* 

set K MATRIX.* to previous value of K MATRIX.* 

exit..." 

Problem: The step before this in the design was to rotate these same variables unconditionally. These 
assignments will cause a second rotation, which is incorrect. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: TDLRSP, PERFORM ALTERNATE 
PROCESSING IF THIS IS AN EVEN-NUMBERED FRAME 

TDLRSP P-Spec 2.9.2, page 2 130 

"if (TDLRSTATEO)" 

"else if (TDLRSTATE > 1)" 

Problem: It is not clear which element in the time history is being checked. If the most recent is 
implied, then there is a problem because the rotation has already taken place but the new elements have 
not yet been calculated. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, Upper or 
Lower Limit Exceeded 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TDLRSP P-Spec 2.9.2, page 3 131 

"if (FRAME_BEAM_UNLOCKED<0 ) " 

"else if (TDLR STATE > 1)" 

Problem 1 : It is not clear which element in the time history is being checked. 

Problem 2: The variable FRAME BEAM UNLOCKED should also be set later on this page (see #34); 
therefore, this is either the incorrect place to check for limits or else they must also be checked 
elsewhere in addition. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 
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** Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, 

Upper or Lower Limit Exceeded 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TDLRSP P-Spec 2.9.2, page 3, MIDDLE of page: 33 

"Test to determine if a beam has locked again:" 

"The beam can now be used * 

TDLRSTATE.# = locked 
FRAMEBEAMUNLOCKED.# = 0" 

Problem: In the Software Requirements document. Table 5.11, line 2, FRAME BEAM UNLOCKED 
is not supposed to be changed, but the design does change it in this case. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: TDLRSP, DETERMINE RADAR BEAM 
STATES 

TDLRSP P-Spec 2.9.2, page 3, MIDDLE of page: 34 

"Test to determine if a beam has locked again:" 

"The beam can now be used * 

else 

*Beam is unlocked and remains unlocked * 
endif 

Problem: In the Software Requirements document. Table 5.11, line 3, FRAME BEAM UNLOCKED 
should be set to the value of FRAMECOUNTER, but in this case (between the "else" and the "endif') 
it is not being changed. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: TDLRSP, DETERMINE RADAR BEAM STATES 

TDLRSP P-Spec 2.9.2, page 3, most of page: 136 

The design checks for conditions in line 1 of Table 5.11 (in specification) and then even if it has found 
and processed the conditions in line 1, it goes on to check and process for conditions for lines 2 and 3. 

The intention in the specification was to only process one line of the table. It is possible that line 1 
would be processed, setting TDLR STATE to locked, and then line 3 could also be processed. This 
would not cause a problem in this case, but this was not the intent of the specification. Perhaps a 
modification to the specification is required. 

TDLRSP P-Spec 2.9.2 32 

Page 3, bottom of page: 

" Average(resolve). . .using the table named AVERAGING DOPPLER RADAR BEAMS IN LOCK..." 

Page 4, middle of page, under CLASS 2, CLASS 3, and CLASS 4: 

In each case it states to calculate average velocity, but does not give the particular equations. One can 
deduce by going back to the comment quoted above from page 3, that one is to use the equations in the 
table, but the comment is not specific enough and has an incorrect table name and does not give the 
table number. In any case, neither the table reference nor the actual equation is given in the design 
body on page 4. 
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*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 1 1.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: TDLRSP, PROCESS THE BEAM 
VELOCITIES 

*Requirement: Translatability to source code (Reference: Software Development Standards, 

Software Design Standards, "The low level requirements should be directly translatable into 
source code, with no further decomposition required.") 

TDLRSP P-Spec 2.9.2, page 4 132 

"if (TDL RVELOCIT Y . * < -100)" 

"else if (TDLR VELOCITY.* > 100)" 

Problem 1 : It is not clear which elements in the time history are being checked. 

Problem 2: Why is one element being checked on page 2 and all elements being checked on 
page 4? 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, 

Upper or Lower Limit Exceeded 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TDLRSP P-Spec 2.9.2 133 

TDLR STATUS has not been checked for limits exceeded. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, 

Upper or Lower Limit Exceeded 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TDLRSP P-SPEC 2.9.2, pages 3 and 4 126 

The notation ".#" 

Problem 1 : Because of this notation, it is not clear where the control loops must be, or, if 
in fact it makes any difference where the loops are. 

Problem 2: The Averaging of the beams beginning at the bottom of page 3 and 
continuing to page 4 cannot be done until all the steps through "Calculate all four 
RADAR beam velocities" has been completed (for all four beams). Because of the 
confusion due to ".#" over where the loops must be, the above fact stated in the previous 
sentence may not be explicitly clear. 
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TDSP, P-Spec 2.10.2 

TDSP, P-Specs 2.10.1 and 2.10.3 (TDSPEXPAND and TDSPCOMPRESS) 140 

These P-Specs do not appear to have any useful function. A P-Spec should perform some 
function that converts its input elements to its outputs. These P-Specs seem to convert from 
control flow group names to element names and back, which is not an actual function. Why 
would there be a P- Spec with no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

TDSP P-Spec 2.10.2, page 1, TITLE 150 

"TDSP - Touch Down Sensor Processing (P-Spec 2.1.6)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.10.2 
which is the correct P-Spec number for this design. The title, on the other hand, contains P- 
Spec number 2.1.6 which is probably from the Software Requirements document. There 
needs to be some clarification here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TDSP, P-Spec 2.10.2, page 2, middle of page 141 

"else 

Give message "TDSSTATUS has bad value..." 

Problem: The only way control could get here is for TDS STATUS to have a value outside 
of its range. This problem would have already been handled by the exception handling on 
page 1, so this pseudocode represents additional functionality over what the specification has 
required. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

TDSP, P-Spec 2.10.2, page 1 and page 2 142 

Question: Why is the TDS STATUS limit check made before the variable is set, while the 
TD SENSED limit check is made after the variable is set. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 
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TSP, P-Spec 2.11.2 


TSP2.11 DFD 

TS STATUS shows as input to TSP, but it is not an input to TSP. It also incorrectly appears as 
"TEMP_GS_IN" (see #93). (See Formal Modification 2.2-17.2). 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

TSP P Spec 2.11.1 and 2.11.3 (Data Expand and Data Compress) 

These P-Specs do not appear to have any useful function. A P-Spec should perform some function that 
converts its input elements to its outputs. These P-Specs seem to convert from control flow group 
names to element names and back, which is not an actual function. Why would there be a P- Spec with 
no body? 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

TSP P-Spec 2.11.2, page 1 , TITLE 

"TSP - Temperature Sensor Processing (P-Spec 2.1.5)" 

Problem: There is some confusion about the P-Spec number. At the top of the page is 2.1 1.2 which is 
the correct P-Spec number for this design. The title, on the other hand, contains P-Spec number 2.1.5 
which is probably from the Software Requirements document. There needs to be some clarification 
here. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

TSP P-Spec 2.1 1.2, page 4 

"Determine which expression to use to calculate THERMOCOUPLE temperature:" 

"if (THERMO TEMP >= lo meas limit tc 
and 

THERMO TEMP < M3..." ... 


"ELSE IF (THERMO TEMP > m4 
AND 

THERMO TEMP <= himeaslimittc)" 

Problem: In the first conditional, the first relational expression is unnecessary, and in the second 
conditional the second relational expression is unnecessary. It is conceivable that these expressions 
could cause a problem. It has previously been determined that the thermocouple sensor should be 
used, and therefore we should not exit from this section without setting ATMOSPHERICTEMP to 
some value base on THERMO TEMP. Since there may be a roundoff in the calculations of 
lo_meas_limit_tc and/or hi_meas_limit_tc, it is possible these unnecessary expressions might cause the 
"if' to yield "false" where it might otherwise yield "true", and the result would be an undefined value 
for ATMOSPHERIC TEMP. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO-178B 
6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: TSP, Calculate the Thermocouple 
Temperature, "Use the value of THERMO TEMP to determine whether the temperature lies in the 
thermocouple linear or the upper parabolic or the lower parabolic region." 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 
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TSP P-Spec 2.11.2 135 

The variable TSSTATUS has not been checked for upper/lower limit exceeded. 

*Requirement: Fullfillment of requirements in Software Requirements document (References: DO- 
178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, Upper or 
Lower Limit Exceeded 

* TSP P-Spec 2.11.2, page 1 154 

"BEGIN LOCAL TYPE DEFS" real*4 ell . . real*4 hold 

END LOCAL TYPE DEFS" 

MISCELLANEOUS P-Specs (not the eleven functional units) 

GENERATESEQUENCEPARMS (store) and GENERATESEQUENCEPARMS P-Spec 
2.18 118 

The fact that GENERATE SEQUENCE PARMS is used as the name for a data store and as the name 
for a process is confusing. Since the store is "not- defined", and since it doesn't appear as a store on 
any of the DFD/CFD diagrams, it's not clear what is its function, if any. (see #60) 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

COPY CONTROL DATA, P-SPEC 2.18, page 1 (see #98 also) 1 00 

"Copy INITSUBFRAMECOUNTER to SUBFRAMECOUNTER" 

There are several problems with this statement. 

Problem: It seems there is no reason to copy SUBFRAME COUNTER to anywhere since it already 
exists in the global data store EXTERNAL. Why is this being done, and what is the purpose for the 
store "SUBFRAMECOUNTERSTORE 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

Problem: INIT SUBFRAME COUNTER is a control flow, while SUBFRAME COUNTER is a data 
flow. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Problem: The use of the name "SUBFRAME COUNTER" is ambiguous because it appears in the 
stores EXTERNAL OLD, SUBFRAME COUNTER STORE, and in the global store EXTERNAL 
(defined in the Software Requirements document but missing from the store EXTERNAL in this 
design document). One can look at the RUN GCS DFD to see that the intention is to store into 
SUBFRAME COUNTER STORE, but the P-Spec itself should be self-contained. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

Potential Problem: If it is intended that SUBFRAME COUNTER in the store EXTERNAL is to be 
changed, then this would be a violation of the requirements because in the Software Requirements 
document, SUBFRAME COUNTER is not an output for any functional unit. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 
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Miscellaneous P-Specs with no body 138 

EMIT EXTERNAL STORE (P-SPEC 2.12) 

STORE RAW SENSOR DATA (P-SPEC 2.13) 

EMIT RUN PARM STORE (P-Spec 2.14) 

INIT GUIDANCE STATE STORE (P-Spec 2.15) 

SEND CHUTE RELEASE COMMAND (P-Spec 2.16) 

SEND ENGINE DATA (P-Spec 2.17) 

It is not immediately clear what is the function of these P-Specs. 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

* Miscellaneous P-Specs with no body 196 

The design states that "This P-Spec exists because Teamwork cannot send data flows off page 
(so an intervening bubble is required)" ; however, this seems to be contradicted by Figures 
2.4 and 2.5 in the Specification. Could this be looked into? 

*Requirement: Completeness (Reference: DO-178B 11.0b) 


Miscellaneous 

Invocation of Rendezvous 119 

There is nothing in the design which states exactly how and when to invoke the rendezvous 
routine. 

*Requirement: Fullfillment of requirements in specification (References: DO-178B 6.3.2a 
and 1 1.10a; Software Requirements 2.2 with Mods 1-26: 

*Requirement: Reference: Software Requirements 2.2 with Mods 1-26, Appendix B, 

"Process", "The calling convention for this GCS SIM provided support utility is as follows: 

9 GCS SIM RENDEZVOUS (requires no parameters) " 

Teamwork Balancing 137 

Question: Has the Teamwork balancing been done? Should this be included in the design? 

General 213 

There are many places in the design where the name of a variable which contains a time 
history is used with no history subscript. An example is GP, P-Spec 2.7.2 where 
GP ALTITUDE and GP VELOCITY are used with no history subscripts. The design should 
find some method for removing this type of ambiguity. 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 
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Typographic Errors, Style, and Grammar 


Introduction 

2.5 Revision History, second statement. Grammar: It's not considered a good practice to use 
the pronoun "I" in a technical document. 

Introduction 

2.4 Transition History, second statement. Clarity: This is not a correct grammatical sentence 
as it has no subject. 

P-Spec 2.1 1.2 

"SERSOR'S" should be "SENSOR'S" 

P-Spec 2.2.2 

"reciept" should be "receipt" 

P-Spec 2.9.2 

"TDLR VELOCITYV" should be "TDLR VELOCITY" 

P-Spec 2.4.5, bottom of page 1 
"accesed" should be "accessed" 

Data Dictionary 

A COUNTER: "accelerating" should be "accelerations" 

Data Dictionary 

A SCALE: "RUN PAREMETERS" should be "RUN PARAMETERS" 

Data Dictionary 

ALPHA MATRIX: "rea*8" should be "real*8" 

DATA DICTIONARY GUIDE SO IN "ATMOSPHEREIC TEMP" should be 
"ATMOSPHERICTEMP" 

DATA DICTIONARY TDLR ANGLES "y;" should be "gamma;" 
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Suggestions for the Future 

It would be helpful if the entire design document were numbered sequentially from beginning 
to end. 

There doesn't seem to be an attempt on part of the designer to simplify equations, (see TSP 
equations for parabola, see eqn for note 1 m3 - m_lo = m3 - [m3...]). Perhaps we could request 
this. 

Constants used for limit checking make modification difficult and error- prone. 

In the pseudocode, nested if s spanning many pages makes the logic extremely difficult to 
follow and may lead to an error-prone inspection. As an example, see AECFP, P-Spec 2.1.2, 
where one nested if begins on page 3, nests to a depth of four, and does not terminate until page 
7. The suggestion is that the standards require that any time an if statement spans more than one 
page, that the if, else, elseif, and endif (or whatever syntax is used) be meticulously labeled in all 
places so that the scope of each "if' is immediately obvious. 

It would be very helpful if the designer, when using an algorithm that is not in the specification, 
gave either a text reference or the derivation of the algorithm and well as an explanation as to 
how it is being applied to GCS. 

The SA charts and tables and entries in the Data Dictionary seem overly complicated and 
difficult to follow. Is there any way we can ask for simplicity of design? We might want to 
simplify the structured analysis diagrams in the specification (minimize the use of control flows). 

It would be helpful if the titles for diagrams could say what that diagram is, eg, DFD/CFD, PAT 
etc 

Is there some way we can add something to the standards to keep designers/coders from using 
code that is completely superfluous? 

Can we add something to the standards to force the designer to be explicit about what is a 
comment and what is actual pseudocode/structured English? 

Can we add something to the standards to force the designer to use very specific non- 
ambiguous language? 

Require that a Teamwork Balance Report (with no errors) be included as part of the design. 
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QUESTIONABLE ITEMS 

Introduction 48 

4. Notation in Pluto Version of GCS Design Page 6, middle paragraph "Another syntax..." 

There is no statement about whether the array under discussion for the current subframe has 

been rotated or is about to be rotated 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

DATA DICTIONARY 

INITRPOUT 88 

The intention here seems to be to duplicate the data flow names in RUNPARAMETERS 
data store. If this is the case, then MAX NORMAL VELOCITY has been omitted. 

*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

DATA DICTIONARY 

F 59 

This has one value, "FALSE". It seems to be a misuse of the Data Dictionary to put a 
constant into it. It is supposed to be used for data flows, control flows and/or data conditions. 
*Requirement: Follow a particular design method (References: Software Development 
Standards, "Software Design Standards", "Design Methods, Rules, and Tools", "...using the 
structured analysis ...by Hatley and Pirbhai or...", and "Design Documentation", "...document 
should follow.. .GCS specification document or the Hatley book...") 

DATA DICTIONARY 

INITRENDEZVOUSCNTL 63 

"RUNNING" 

Question: This element is a constant. Why is it in the data dictionary? 

*Requirement: Follow a particular design method (References: Software Development 
Standards, "Software Design Standards", "Design Methods, Rules, and Tools", "...using 
the structured analysis ...by Hatley and Pirbhai or...", and "Design Documentation", 

"...document should follow.. .GCS specification or the Hatley book...") 

DATA DICTIONARY 

INITSUBFRAMECOUNTER 64 

tt J II 

Question: This element is a constant. Why is it in the data dictionary? 

*Requirement: Follow a particular design method (References: Software Development 
Standards, "Software Design Standards", "Design Methods, Rules, and Tools", "...using 
the structured analysis ...by Hatley and Pirbhai or...", and "Design Documentation", 

"...document should follow.. .GCS specification or the Hatley book...") 
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NOT USED 


DATA DICTIONARY 126 

TD LN DRADG S IN TDLR STATUS is not an input from GUIDANCESTATE store to 
TDLRSP. 

STORE RAW SENSOR DATA, P-Spec 2.13 82 

This P-Spec does not perform any function traceable to the Software Requirements document. 

(see #81) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

INIT RUN PARM STORE, P-Spec 2.14 85 

This P-Spec does not perform any function traceable to the Software Requirements document. 

(SEE #84) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

INIT GUIDANCE STATE STORE, P-Spec 2.15 87 

This P-Spec does not perform any function traceable to the Software Requirements document. 

(SEE #86) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

DATA DICTIONARY, pages 1 8 and 1 9 113 

The element EXTERNAL is defined as a store but yet is shown as a group flow name. This is 
not consistent. 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

DATA DICTIONARY, pages 1 8 and 1 9 114 

The element EXTERNAL is shown as a group flow name; however, some of the primitive 


elements in the group (e.g. AE CMD, FRAME COUNTER) are repeated several times in the 
list). 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 

DATA DICTIONARY ,page 43 1 8 

Introduction 

CALLING STRUCTURE (reword???) 1 1 0 

The calling structure, especially in terms of rendezvous, is not shown directly. 

Introduction 38 

1.1 Top-Level Description, first paragraph 
The wording "touch-down switch" is not an accurate description. 

* Requirement: Accuracy (DO-178B 6.3.2 b) 
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Individual Inspection Preparation Log #1 (Page 54) 

Name: Bernice Becher Date Log Submitted; 

Implementation: Pluto Date of Inspection 

Role: Inspector 

Defects/Clarity Problems/Concems 


October 15, 1993 
October 15, 1993 


*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

2 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

3 

*Requirement: Follow a particular design method (References: Software Development 
Standards, "Software Design Standards", "Design Methods, Rules, and Tools", "...using the 
structured analysis ...by Hatley and Pirbhai or...", and "Design Documentation", "...document 
should follow.. .GCS specification or the Hatley book...") 

4 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

5 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 6.3.2a, and 11. Of) 

6 

*Requirement: Translatability to source code (Reference: Software Development Standards, 
Software Design Standards, "The low level requirements should be directly translatable into 
source code, with no further decomposition required.") 

8 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

10 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

11 

*Requirement: Fullfillment of requirements in Software Requirements document (References: 
DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, Exception Handling, 
Upper or Lower Limit Exceeded 


Added since last design review of 10/15/93 

Two typos were by mistake in the data dictionary. They were moved to the 
typos. 

A suggestion was added to require that the design include a balancing report. 
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Review Log from Verification Analyst 


Individual (Design) Inspection Log 10/15/93 (Final) Page 1 of _7 

Rob Angellatta 

Pluto 


General Deficiencies 

The overall quality of the Pluto design is disappointing. Listed below are several general comments supporting 
this opinion. Preparing a problem report for the listed items is probably unnecessary, however some feedback on the 
“sloppiness" of the design may prove beneficial. 

o The syntax for referencing array data as described on page 6 of the "Design Description Document - Pluto" is 
confusing and inconsistently followed. For example, as found on page 6, "The in equations following a 
variable name or comment indicates independent iteration over each of the 3 lander body axis directions: x, y, 
& z." P-Spec 2.2.2 ARSP contains the following operation: "ARALTITUDE.* = ..." The data element 
ARALTITUDE is an array and represents history data, not vehicle axial data. Thus, the reference is 
inconsistent with the defined usage. Additionally, also in P-Spec 2.2.2 ARSP, the current value of the vehicle 
altitude is referenced in one location as AR_ALTITUDE.[0], and in another location referenced as 
AR ALTITUDE.*, providing another example of inconstant (and incorrect) use of the defined syntax. 

o There are several instances where the design should contain a brief description of the designer's intentions. 

For instance, in P-Spec 2.11.2 TSP several operations are presented for computing the temperature from the 
solid-state temperature sensor. A brief narration of the intent of the operations is in order. 

o And then, there are several instances where a description of a solution is provided, but no algorithm for 

implementing the solution is presented. For instance, in P-Spec 2.2.2 ARSP a thorough (although incorrect) 
description of the Newton Divided Difference Method for extrapolation is provided, but no algorithm for 
implementing the method is presented. This example is poignant because the description of the method is 
flawed. So the question arises, does the designer really understand the method (and its application) merely 
mistaken in the explanation or does the designer not really understand the method? An algorithm 
implementing the solution would certainly provide the necessary insight into the designers understanding of 
the problem and the proposed solution. 

o At the design level of abstraction a data element of type "logical" can assume one of two values, namely 
"TRUE" or "FALSE." The Pluto design contains many references to data element of type logical assigning 
values of "0", "1", "healthy", "failed", and so forth. Technically, it is incorrect to refer to a "logical" data type 
as any value other than "TRUE" or "FALSE." I do not attribute this deficiency to the Pluto design so much as 
to the GCS Programming Specification. The spec is full of such references and it is this type of mistake 
which significantly contributes to the "sloppiness" and "amateur" appearance of both the programming 
specification and the Pluto design. 

o A comparison of the Pluto data dictionary entries (DDE) with the DDE's of the programming specification 
uncovers defects for the following entries: 

o A COUNTER — A typo in the "description" field. 

o COMMSYNCPATTERN - The value specified in the "range" field is ambiguous. The value is 
apparently a bit pattern, however the chosen syntax for expressing this value does not make this fact 
clear. This defect also appears in the programming specification. 

o GP DONE — Missing the field "data type." 

o K MATRIX — The value of the field "accuracy" is inconsistent with the programming spec. 

o THETA1 — The field "data store location" does not exist. 
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Individual (Design) Inspection Log 

Rob Angellatta 

Pluto 


Page 2 of _7 


Defects/Clarity Problems/Concerns 

Location Description 

1 EXTERNAL The Pluto design contains a data store labeled 

data store "EXTERNAL." However, Pluto's "EXTERNAL" data store is inconsistent with the 

programming specification (missing data elements "PACKET" and "SUBFRAME COUNTER") . (Note, 
Pluto's "EXTERNAL OLD" data store is consist with the programming specifications "EXTERNAL" data 
store.) See the SPEC pgs. 13-14 for requirements and table 6.2 on page 98 for data store description. 

2 GUIDANCE STATE The Pluto design contains a data store labeled 

data store "GUIDANCE STATE." However, Pluto's "GUIDANCE STATE" data store is inconsistent 

with the programming specification (contains additional data elements "TDLRSP SWITCH" and 
"TDSP SWITCH"). See the SPEC pgs. 13-14 for requirements and table 6.1 on page 97 for data store 
description. 

3 SENSOROUTPUT The Pluto design does not contain the required 

data store data store labeled "SENSOR OUTPUT." However, Pluto's "SENSOR DATA" data store 

appears to be consistent with the programming specification for the data store "SENSOR_OUTPUT." See 
the SPEC pgs. 13-14 for requirements and table 6.3 on page 98 for data store description. 

4 P-Spec 1, INITGCS The low-level specifications for this process should not be specified in the 

Pluto design. The programming spec, page 3 1 "LEVEL 2 SPECIFICATION" , clearly states, 
"INITGCS ... are not the responsibility of the programmer." 

5 P-Spec 3, 

GENERATE SEQUENCE P ARAMS Missing algorithms. Insufficient detail is specified as to how to 

determine the state of theredata elements "ITH FRAME 2" and "ITH FRAME 5." It is not clear weather 
or not the designer truly understands which frames are the "ith_frame_2s" and which frames are 
"ith_frame_5s." Assume that the Pluto design description was given to a programmer for code 
implementation. Would the programmer clearly understand which frames to designate "ith_frame_2" and 
which frames to designate "ith_frame_5" from this description? 

6 P-Spec 0-sl, RUNGCS PAT Inconsistent with P-Spec 2. si. The PAT appear to specify that the 

order of process execution for the processes "RUN GCS" and "GENERATESEQUENCEPARMS" is 
insignificant. However, P-Spec 2. si which controls the processing within the process RUN_GCS clearly 
depends upon the value of the data elements "ITH FRAME 2" and "ITH FRAME 5" which are updated 
in the process "GENERATE SEQUENCE PARMS." 

7 ?? GCSSIMRENDEZVOUS ?? There is an obvious absence of the process 

GCSSIMRENDEZVOUS. The programming spec page 31, LEVEL 2 SPECIFICATION clear states 
"There should be a call to GCS SIM RENDEZVOUS, prior to executing each subframe." 

8 P-Spec 2, RUN GCS There are a number of control signals defined, data elements like 

"AECLP DONE", "ASP DONE" and so forth. Where are these control signals set/reset? I can not find 
any evidence to suggest these signals are properly manipulated? It's frustrated — we "know" how they are 
supposed to be manipulated, but how would a programmer "know" from just the design? 
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Rob Angellatta 

Pluto 


Page 3 of 7 


Defects/Clarity Problems/Concems 


Location Description 

9 P-Spec 2.11 .2; 1 0 TSP The design assumes that (M3, T3) < (M4,T4). This is a valid assumption only 

because figure 5.4 implies this is true. Other then figure 5.4, the spec is not clear on this 
point. 

10 P-Spec 2.1 1.2;10 TSP ??? Inconsistency. The data element "TS STATUS" is designated Input/output on 

the bubble diagram 2.1 1. The data element "TS STATUS" is designated output in the P- 
Spec 2.1 1.2;10. The programming specification lists "TS STATUS" as output. 

11 P-Spec 2.1 1.2; 10 TSP I believe that the method for computing the temperature from the solid state 

temperature sensor requires an explanation, some narration. 

12 P-Spec 2.1 1.2; 10 TSP The method for computing the upper and lower limits of the thermocouple 

temperature sensor range most definitely requires an explanation, some narration. 

13 P-Spec 2.2.2;22 ARSP 

14 P-Spec 2.2.2;22 ARSP The syntax ARALTITUDE.*, ARSTATUS.*, and KALT.* is inconsistent with 

the definition of".*" as specified in the "Design Description Document — Pluto" page 7. 

15 P-Spec 2.2.2;22 ARSP There are several instances where a data element is assigned a previously computed 

value of a data element, denoted by the expression "[previous value." In these instances, 
four previously computed values are available for the assignment. The intent is to assign 
the most recently computed value, not just any previously computed value. Thus, in these 
instances the design is ambiguous as to which previously computed value is used for the 
assignment operation. 

16 P-Spec 2.2.2;22 ARSP When computing the altitude in the case where an echo is received, a check for the 

exception condition "upper limit exceeded" is absent. 

17 P-Spec 2.2.2;22 ARSP The description of the Newton Dividend Difference method for extrapolation — I 

expect to see this description in the "Design Description Document." However, here in the 
design itself, I expect to see an algorithm implementing this method. Thus, I believe that 
the design provides insufficient detail. 

18 P-Spec 2.2.2;22 ARSP The description of the Newton Dividend Difference method for extrapolation — 

The first step under "construct a table of divided differences" states "The first column of 
the table holds the four previous altitudes." The ordering of the four previous value is 
significant, however the ordering of the four previous values if unspecified. Thus, the 
statement is ambiguous. 

19 P-Spec 2.2.2;22 ARSP The second, third, and forth steps under "build a polynomial" state "... the first 

(most recent) index in column ..." These references are inconsistent with step one where 
the most recent value is located in the last element of the column. 
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Pluto 
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Defects/Clarity Problems/Concerns 


Location Description 

20 P-Spec 2.2.2;22 ARSP When computing the altitude in the case where a value must be extrapolated from 

the previous computations, there is an absence of checks for the exception conditions 
"lower limit exceeded" and "upper limit exceeded." 

21 P-Spec 2.2.2;22 ARSP When reporting the altitude as the most recent previously reported value, the 

statement "ARALTITUDE.* = ARALTITUDE. [previous value" is deficient. First, the 
syntax is "ARALTITUDE.* " is inconsistent with with the definition of".*" as specified 
in the "Design Description Document — Pluto" page 7. This is really sloppy as the 
appropriate syntax is used earlier in the P-Spec. Second, the statement "[previous value" 
is ambiguous. 

22 P-Spec 2.9.2; 17 TDLRSP Rotate Variables -- Insufficient detail in description of the proposed method. The 

phase "shift the data" is ambiguous. 

23 P-Spec 2.9.2; 17 TDLRSP The syntax "TDLR VELOCIT Y. * " and "K MATRIX.*" is inconsistent with the 

definition of".*" as specified in the "Design Description Document — Pluto" page 7. 

24 P-Spec 2.9.2; 17 TDLRSP The statements "set ... to previous value of..." are ambiguous. 

25 P-Spec 2.9.2; 17 TDLRSP Typo. "TDLR VELOCITYV.*" 

26 P-Spec 2.9.2; 17 TDLRSP Questionable assignment: "FRAMEBEAMUNLOCKED.# = 0." Technically, 

table 5.11 (case 2) on page 69 of the programming specification clearly indicates that this 
assignment should not be made. However, I don't really see a problem with this action 


27 P-Spec 2.9.2; 17 TDLRSP Insufficient detail. There is a thorough description of processing the beam 

velocities. However, the description is merely a prose version of the programming 
specifications table 5.12. Reference is made to "calculating average velocities," but a 
description of how to calculate average velocities is noticeably absent. An algorithm 
implementing the solution is in order (or merely a reference to table 5.12 may suffice). 

28 P-Spec 2.10.2;12 TDSP COSMETIC. Valid values for the status of the touchdown are healthy (0) and 

failed (1). The P- Spec references the failed status as "unhealthy." This inconsistency with 
the programming specification is potentially confusing. 

29 P-Spec 2.10. 2;12 TDSP SYNTAX. The local integer constant "all ones" has a value of -1. An assumption 

is made that integers will be represented in two's complement — thus in a 16-bit value of -1 
all 16 bits are set (ie. T). I question the validity of this assumption. Note, P-Spec 2.2.2;22 
ARSP declares a similiar constant using a preferred syntax. 

30 P-Spec 2.3.2;21 ASP QUESTION? When declaring the 'local type defs' should these variable have type 

real* 8? what precision is required? 

31 P-Spec 2.3.2;21 ASP INSUFFICIENT DETAIL. The description for "rotating the variables" is 

ambiguous. The phase "shift data" is ambiguous. 
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Defects/Clarity Problems/Concerns 

Location Description 

32 P-Spec 2.3.2;21 ASP IN SUFFIECENT DETAIL. When "correcting for misalignment of the accels" it is 

not clear if a matrix multiplication is specified. 

33 P-Spec 2.3. 2;21 ASP AMBIGUITY. When computing the standard deviation the syntax of the 

mathimatical operation is not clear. 

34 P-Spec 2.6; 1 GSP dfd DEVIATION FROM SPEC. The data element G_STATUS apears as input to GSP. 

35 P-Spec 2.6.2;9 GSP INSUFFICIENT DETAIL. The description for "rotating the variables" is ambiguous. 

The phase "shift data" is ambiguous. 

36 P-Spec 2.6. 2;9 GSP QUESTION. The local data element "at" is used to buffer the value found in the 

element "atmospherictemp." Note, "at" is of type real*4 while "atmospheric temp" is of 
type real*8. Is the lost of numeric precision acceptable? How about the precesion of the 
other local data elements? 

37 P-Spec 2.6. 2;9 GSP QUESTION. The use of the operator "1AND." Is this acceptable and what is the 

operation? This is not provided in FORTRAN-88. 

38 P-Spec 2.6.2;9 GSP ????? When converting to twos-comp, the then case — The proposed solution is not a 

twos-comp function. 

39 P-Spec 2.6.2;9 GSP ????? When converting to twos-comp, the "else" case is not necessary. 

40 P-Spec 2.7.2;29 GP INSUFFICIENT DETAIL. The description for "rotating the variables" is ambiguous. 

The phase "shift data" is ambiguous. 

41 P-Spec 2.7. 2;29 GP AMBIGUITY. The syntax is not used as defined in the document description 

documentation. 

42 P-Spec 2.7.2;29 GP AMBIGUITY. There are several reference to a one diminsional data element 

GP VELOCITY, GPALTITUDE, and GP ATTITUDE. 

43 P-Spec 2.7.2;29 GP AMBIGUITY. When computing the current values of the vehicle altitude, velocity, 

and altitude, the assignment statements are inconsist with the assignment operator "=". 

44 P-Spec 2.7. 2;29 GP AMBIGUITY. The data element "tnow" is used but not defined. 

45 P-Spec 2.7.2;29 GP DEVIATION FROM SPEC. The lower limit of GP ALTITUDE is incorrectly 

evaluated with the value -1. 

46 P-Spec 2.7.2;29 GP DEVIATION FROM SPEC. The lower limit of FRAME ENGINE IGNITED is 

incorrectly evaluated with the value -1. 

47 P-Spec 2.7.2;29 GP ??????? The statemant "else if (FRAME ENGINESJGNITED > 2**31-1)" is not 

valid (or necessary). The data element FRAME ENGINES IGNITED is speed as 
Integer*4. The maximum value for this data type is 2**(31-1). 
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Defects/Clarity Problems/Concerns 

Location Description 

48 P-Spec 2.7.2;29 GP DEVIATION FROM SPEC, The data element AE TEMP is not examined 

for exceeding the upper limit. 

49 P-Spec 2.7.2;29 GP I have some difficulty following the determination of the current phase. 

Some portions are clearly incorrect. 

50 P-Spec 2. 7.2;29 GP INSUFFICIENT DETAIL. Need some algorithms for interpolation and 

extraplolation for computing the velocity error. 

51 P-Spec 2.7.2;29 GP AMBIGUITY. The data element "second" is referenced, but not defined. 

52 P-Spec 2.7.2;29 GP DEVIATION FROM SPEC, The appearant computation of the velocity 

error is incorrect. 

53 P-Spec 2. 1 ,2;3 1 AECLP In the section "determining the axial engines' temperature — is this the 

algorithm or a comment? I do not see the actual data assignment. 

54 P-Spec 2. 1.2;31 AECLP AMBIGUITY — There are references to a one diminsional array data 

element GPVELOCITY. "the" GPVELOCITY is a two diminsional array data 
element. 

55 P-Spec 2. 1 ,2;3 1 AECLP DEVIATION FROM SPEC, When computing the PE INTEGRAL, 

there is a noticable absence of the abs functions for the GP VELOCITY(l) term 
when computing the local data element theta. 

56 P-Spec 2. 1 ,2;3 1 AECLP DEVIATION FROM SPEC, When computing the YE INTEGRAL, 

there is a noticable absence of the abs functions for the GP VELOCITY(l) term 
when computing the local data element theta. 

57 P-Spec 2. 1 .2;3 1 AECLP DEVIATION FROM SPEC, The upper bounds check of the data 

element CONTOUR CROSSED is flawed. 

58 P-Spec 2. 1 ,2;3 1 AECLP DEVIATION FROM SPEC, The data element TE LIMIT is not 

updated with the proper value. 

59 P-Spec 2. 1 ,2;3 1 AECLP DEVIATION FROM SPEC, Page 7, "if (AE SWITCH = off)" 

condition, the processing is not defined in the spec. Is it appropriate? 

60 P-Spec 2. 1.2;31 AECLP 

61 DFD 2.8;4 RECLP The data element RE STATUS is displayed as an input to the process 

RECLP. 

62 P-Spec 2. 8.2; 1 3 RECLP INSUFFICIENT DETAIL. When determining the roll engine command 

from the graph. 
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Defects/Clarity Problems/Concerns 

Location Description 

63 DFD2.4;16CP DEVIATION FROM SPEC. There are a number of data elements displayed 

as input to CP which as not specified in the spec. AESWITCH, RE SWITCH, 
TDLRSPSWITCH, TDSPSWITCH, TELIMIT, THETA, 

FRAME BEAM UNLOCKED, FRAMEENGINESIGNITED, 

INTERN AL CMD, CL. 

64 DFD 2.4; 16 CP DEVIATION FROM SPEC, The control signal SUBFRAME COUNTER 

appears as input to the process CP. 

65 P-Spec 2.4.2;25 CP DEVIATION FROM SPEC, "subframe 1, ith_frame_2 and not 

ith_frame_5" (class f) processing — the comments do not refer to the data 
elements KALT and KMATRIX bits as set in the sample mask. Then, the 
KALT bit is set, however the K MATRIX bit is not set. 

66 P-Spec 2.4.2;25 CP DEVIATION FROM SPEC, Class F processing — the data element 

K MATRIX is not loaded into the packet correctly. 

67 P-Spec 2.4.2;25 CP DEVIATION FROM SPEC, subframe 1, not ith_frame_2 and ith_frame_5 

(class G) processing — when accually loading the data elements into the data 
buffer, the following data elements are not loaded: AACCELERATION, 

A STATUS, C STATUS, GROTATION, and G_STATUS. 

68 P-Spec 2.4.2;25 CP DEVIATION FROM SPEC, "subframe 1, ith_frame_2, ith_frame_5" (class 

A) processing — the data elements K ALT and K MATRIX bits are not set in the 
sample mask. 

69 P-Spec 2.4.2;25 CP DEVIATION FROM SPEC, Class A processing — when actually loading 

the data elements into the data buffer, the following data elements are not loaded: 
A ACCELERATION, A STATUS, C STATUS, G ROTATION, G STATUS, 
K ALT, and K MATRIX. 

70 P-Spec 2.4.2;25 CP DEVIATION FROM SPEC, subframe 2, (Class B) — the data element 

GP ROTATION is not loaded into the packet correctly. 

71 P-Spec 2.4.2;25 CP AMBIGUITY. The calling syntax and argument usage of the process 

CRC- 1 6 is not clear 

72 P-Spec 2.4.2;25 CP The data elements BYTE PACKET, NBYTES, and CHECKSUM are 

reference but never defined. 

73 P-Spec 2.4. 5;8 CRC-16 ?????? It is not clear how the algorithm for computing the CRC operates. 

Some narration and/or reference is required. 
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C.2 Pluto Design Review 


Attendees: Kelly Hayhurst (SQA representative/Moderator) 

Patrick Quach (Verification Analyst/Recorder, Inspector) 
Rob Angellatta (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/Inspector) 

C.2.1 Review Notes from Design Review 


Pluto Design Review 

July 13, 1994 

Session 1: 9:30 a.m. - 1 1:30 p.m. 

High-Level Structured Analysis Diagrams 
Context diagram: 

Telemetry packet flow not illustrated. Need modify to include 
DFD GCS Level 0 specification 

B - 358 — Lower level diagrams should reflect changes for telemetry packet 
DFD GCS Level 1 specification 

B - 354 — Unlabeled data flows to and from GCSSIMRENDEZVOUS - comment to be added 
in introduction 

DFD GCS Level 2 specification 

B - 355 — Bubbles .1 & .3 should reference their counterpart in DFD 1. 

DFD GCS Level 3 specification 

B - 356.3 - INTERNAL CMD not shown as input into AECLP. Need to add to the Dataflow. 


GCS SIM RENDEZVOUS 


B - 342 - Extra unnecessary comment using personal pronoun. - To be deleted 

Altimeter Radar Sensor Processing (ARSP1 

B - 318, P-1 — FRAME COUNTER is not an input to ARSP — should be removed 

B - 3 19 — Syntax problem — The use of E in the constant for the transmission speed (if 

FORTRAN notation is going to be used — should use D instead of E for accuracy) 

B - 3 16.2, P-2 — Problem with limit checks for ARALTITUDE - Limit checking missing for 
ARALTITUDE before using for extrapolation 
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Accelerometer Sensor Processing (ASP) 

B - 307, B - 316, P - 3 — Limits checking for AACCELERATION need to check for 

negative square root 

Question: Does the range checking have to be performed on A ACCELERATION 
before it is used to calculate the mean and standard deviation for each axis. It is a real*8 
from SENSOR OUTPUT data store. 


Gyroscope Sensor Processing (GSP) 

B - 308 — problem with whether G COUNTER(I) has a negative sign — current syntax may not 
be appropriate. 


Temperature Sensor Processing (TSP) 

P-7 - Lower parabolic function (pg. 3): 

There appears to be a typo in the substitution of "h" into the parabolic equation. Either 
there is an extra set of parentheses or the sign after the M3 should be a "+" 

B - 3 1 3 — Incorrect term in the comments in upper parabolic function derivation. The first 
equation should be y = (l/4*p) * (x - h) A 2 + k 


Touch Down Landing Radar Processing (TDLRSP) 

B - 320 — The total number of radar beams is not explicitly expressed in the P-Spec. Only 

implicit in the table. The same indication should be used for maximum number of axis 
in other P-Spec. 

B - 322, P-4 — Concerning the set of IF statements for determining radar beam states (Table 5.11) 
The design meets all the requirements but has extra branches that are not specified in the 
Requirements. 

B - 323 — case 15 while computing “b” there is an incorrect operator; in equation for “pbvY”, 
there is an incorrect operator 

B - 321 — elapsed time calculation should not be within comments 

P-6 — problem with range for TDLR ANGLES in Data Dictionary 

B - 309, P-5 — should off-diagonal elements of K MATRIX be set? 

Touch Down Sensor Processing (TDSP) 

No Problem s 

END OF SESSION 1 
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Session2: July 13, 1994 1:00 p.m. - 3:00 p.m. 


Guidance Processing (GP) 

B - 328 - TEINTEGRAL not an input for GP 
B - 330 — Comment and Pseudo-code not clearly delineated 

B - 33 1 — The algorithm does not specify which history variable to use when calculating the 
altitude (need more detail) - current pseudocode not directly translatable to source 

B - 303 — The derivation for GP VELOCITY uses GPROTATION, but no explanation is given 
on how its derived from GROTATION 

B - 332, P-9 - wrong history variable is used in setting up GP ROTATION (pg. 5): 

Question: Should the most recent values for G ROTATION be used to build 
GPROTATION? 

B - 333 — Negative square-root check not performed in the "if' statement on page 7 

B - 335 — Divide by zero check — there is added information in the exception handling messages. 

B - 336, P-9 — The Else branch for "CONTOUR ALTITUDE(i) < cur altitude" (pg. 8): 

The index is missing from the first part of the IF condition. It should be 
"CONTOURALTITUDE(i)". 

B - 338 — The END GCS signal should not appear in the P-Spec if its not implemented. Use 
GP PHASE instead. 

B - 3 16.4 - missing range checking for variables used in the RK method. 

Axial Engine Control Law Processing (AECLP) 

B - 301 -- problem with order of execution of operators 
P-16 — problem with <= 

B - 304, P-15 — value of e is not correct 

P-12 — an extra check is made for divide-by-zero 

B- - 302, P-13 — problem with computation of yawerrorlimit — it contains an incorrect term 
P-14 — problem with process step enumeration. 

Roll Engine Control Law Processing (RECLP) 

B - 3 1 1 , P- 1 1 — there are 3 cases where RE CMD is not set correctly 
B - 312 — in the "else" statement for deriving roll engine command, the sign of THETA2 is 
incorrect 
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Chute Release Control Processing (CRSP) 


B - 339 — problem with “released” (released not used in this process 
B - 340, P - 17 — problem with limit checks — format statements not needed 


Communications Processing (CP) 

B - 400 — presentation of ere table — need more detail 
B - 40 1 — subscript incorrect in KMATRIX 
B - 402.1 — syntax problems — use of " A " for pointers 
B - 402.2 — need to note number of bits in CRC 

B - 402 3 — In the looping through bytes, the byte order is not specified. 

B - 403 - The XOR operation is does not specify specifically that the lower byte of the CRC is to 
be used 


Data Dictionary 

B - 345 - Order within data stores needs to be explicitly stated. 

B - 349-352, P-21-29 — several elements have problems: AETEMP, CL, 

CONTOUR CROSSED, DROP HEIGHT, Gl, G2, GVEI, K MATRIX, 
TDLR ANGLES, TE DROP, GP GS IN 


General 


B - 325 - use of "RETURN" at the end of some P-Specs should be consistent (Is use of RETURN 
appropriate in a P-Spec?). 


END OF SESSION 2 
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C.2.2 Review Logs from Design Review 


Review Log from System Analyst 


_July 12, 1994 
July 7, 1994 


INDEX 


Individual Inspection Preparation Log #1 (Page 1) 

Name: Bernice Becher Date Log Submitted: 

Implementation: Pluto Date of Inspection: 

Role: Inspector 

Defects/Clarity Problems/Concems 


General Problems 
Limit Checks 
Introduction 

High-Level Structured Analysis Diagrams 

ARSP, P-Spec 1.2 

ASP, P-Spec 1.3 

GSP, P-Spec 1.4 

TDLRSP, P-Spec 1.5 

TDSP, P-Spec 1.6 

TSP, P-Spec 1.7 

GP, P-Spec 2.2 

AECLP, P-Spec 3.2 

RECLP, P-Spec 3.4 

CRCP, P-Spec 3.3 

CP, P-Spec 1.8, 2.3, 3.5 

GCSSIMRENDEZ V OUS, P-Specs 1.1, 2.1, and 3.1 
Data Dictionary 
Typographic Errors 
Suggestions for the Future 
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Individual Inspection Preparation Log #1 (Page 2) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 


General Problems 

NOTATION 306 

" A " is used in ASP, page 3, first equation, and in other places without 
being explained. 

"==" is used without being explained. 

*Requirement: nonamb 

PSEUDOCODE SYNTAX 359 

The pseudocode syntax used in the P-Specs has not been described. 

GLOBAL DATA STORES 3 1 7 

The design does not give instructions for a FORTRAN program for declaring the four global 
data stores as labeled common blocks and how to name them. 

Even though this is a coding detail, it is given in the specification. 

*Requirement: comp, nonamb 

GCSSIMRENDEZ V OU S 327 

The design does not state that in the code, this process must actually be called by the name 
GCS SIM RENDEZVOUS. Even though this is a coding detail, it is stated in the 
specification. 

*Requirement: comp, nonamb 

"return" in P-Specs 325 

Several of the P-Specs contain a "return" before the "END P SPEC". Since "return" is really a 
coding entity, it does not seem appropriate in a P-Spec. The processes which contain this are: 

ASP 

ARSP 

GSP 

RECLP 

TDLRSP 

TDSP 

TSP 

GP 

*Requirement: trace 

ARRAY NOTATION(nnp) 329 

In most (or all) cases (see eg, GP, TDLRSP) where a rotation is to be done, the array notation 
does not use variable indices. This cannot be considered an error; however if this notation 
were to be carried over into the implementation into code, it would be quite error-prone, 
difficult to check for errors, difficult to maintain in the case of changes to the requirements, 
and involves many more lines of code than would otherwise be necessary. This notation is 
also used in other places besides rotation, as for example in AECLP where 
INTERN AL CMD is converted to AE CMD. 

*Requirement: modif 


C-78 



Individual Inspection Preparation Log #1 (Page 3) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

Limit Checks 


GENERAL LIMIT CHECKING: 3 1 5 

In each case in which the design says to produce limit checking output, it 
uses the term "display-error" which does not seem to be defined anywhere. 

Specifically, the information missing in the design is the output logical 
unit number and the formats for FORTRAN code. Even though these are coding 
details, they are stated in the specification. It is not necessary to give 
this information for each incidence of a limit check, but it could be done at 
least once. 

*Requirement: trans, comp 

(Reference: Software Development Standards, Software Design Standards, 

"The low level requirements should be directly translatable into source 
code, with no further decomposition required.") 

SPECIFIC LIMIT CHECKING PROBLEMS 3 1 6 

2. Limit check for ARALTITUDE is not being done in the first subframe before 
it is used to fit a polynomial. 

3. In CRCP, the variables CHUTE RELEASED and AE TEMP are being subjected to 
limit checks, but neither of these is of type real* 8. 

4. The following variables are not being checked for limits in the second 
subframe before being used in the Runge-Kutte calculations: 

AACCELERATION 

ARALTITUDE 

GPALTITUDE 

GPATTITUDE 

GPVELOCITY 

GROTATION 

TDLRVELOCITY 

*Requirement: spec 
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Individual Inspection Preparation Log #1 (Page 4) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

INTRODUCTION 


Derivation Notes 

Abbreviations 343 

Any abbreviations used in any of the notes on derivations should be 
precisely defined. Some examples are GRAV, VELERROR, ATT. 

AECLP, Derivation of Solution for Differential Equation 305 

Problem 1 : On the second page, there is an equation which is not correct, namely TELIMIT = 
Q/OMEGA + C 

Problem 2: On the second page, it is not clear at all how one goes from the equation 
TE LIMIT = Q/OMEGA + C x Q x e-Wt 
to the final equation for TE LIMIT. (specifically, how does one solve for C?) 

*Requirement: ace, nonamb, comp 

GP notes, Derivation for interpolation/extrapolation 344 

1. The second paragraph which begins "Given the point..." has omitted some important 
defining information, namely: 

xO < x < xl ("which is less than the desired point" is not specific") 

xO and xl are contiguous points in the table 

xi represents altitude; f(xi) represents desired velocity at xi 

2. (not an error) The discussion has not included the case where x = xi (even though it is 
handled in the p-spec). 

3. (not an error) The text does not note that all three equations are exactly the same (which 
could make the GP p-spec simpler and more straightforward). 

*Requirement: nonamb, modif, comp 

GP notes, Derivation for attitude, velocity, and altitude: 

1 . The equation for the derivative of GPVELOCITY has the order of 
GPVELOCITY and GP ROTATION reversed in the matrix multiplication. 

2. ACCEL is not a 1 x 3 matrix. 

3. Coding syntax, such as the do loop on page 2, is not appropriate for a derivation. 

4. The equations for the derivatives of GPATTITUDE, GP VELOCITY, and 
GP ALTITUDE, are given on page 2 and then are repeated on page 5-6 (with the 
GP ATTITUDE equation incorrect on page 5). 

*Requirement: spec, ace, modif 
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Individual Inspection Preparation Log #1 (Page 5) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

STRUCTURED ANALYSIS DIAGRAMS 


GCS Context Diagram 353 

PACKET does not appear on any flow going out from the bubble GCS to the telemetry 
external sink. 

GCS DFD/CFD 358 

PACKET does not appear on flows coming from each of the three subframe bubbles and going 
off-page. 

Sensor Processing Subframe DFD/CFD 354 

1. It has not been made clear that the data flows going out from GCSSIMRENDEZVOUS to 
GUIDANCESTATE, RUNPARAMETERS, and SENSOR_OUTPUT are actually valid only for 
the first frame. 

2. The data flow coming out of GCS_SIM_RENDEZVOUS and going to EXTERNAL 
indicates that all variables in that store are on the flow, but this is not correct. 

3. PACKET does not appear on a flow out from GCS SIM RENDEZVOUS to off-page. 

Guidance Processing Subframe DFD/CFD 355 

1. PACKET does not appear on a flow out from GCS SIM RENDEZVOUS to off-page. 

optional 

2. The bubble 2.1 does not contain "(1.1)" inside, and the bubble 2.3 does not contain "(1.8)" inside. See 
Hatley, page 143 regarding notation for multiple use of one process. 

3. The data flow coming out of GCS_SIM_RENDEZVOUS and going to EXTERNAL 
indicates that all variables in that store are on the flow, but this is not correct. 

4. There should be no flows from GCS_SIM_RENDEZVOUS to GUIDANCE STATE, 
SENSOROUTPUT, or RUN PARAMETERS. 

Control Law Processing Subframe DFD/CFD 356 

1. PACKET does not appear on a flow out from GCS SIM RENDEZVOUS to off-page. 

2. The bubble 3.1 does not contain "(1.1)" inside, and the bubble 3.5 does not contain "(1.8) inside". See 
Hatley, page 143 regarding notation for multiple use of one process. 

3. (nnp)The data flow coming from GUIDANCE_STATE to AECLP does not include 
INTERNAL CMD, but it is an input to AECLP. (Note: this is a result of Formal Modification 2.3- 
3.2). 

4. The data flow coming out of GCS_SIM_RENDEZVOUS and going to EXTERNAL 
indicates that all variables in that store are on the flow, but this is not correct. 

5. There should be no flows from GCS_SIM_RENDEZVOUS to GUIDANCE STATE, 

SENSOR OUTPUT, or RUN PARAMETERS. 
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Individual Inspection Preparation Log #1 (Page 6) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

ARSP, P-Spec 1.2 


ARSP, INPUT/OUTPUT Section 3 1 8 

FRAMECOUNTER is not an input to this process. This is probably due to an 
error in the specification, which will be modified. 

*Requirement: ace, trace 

ARSP, first line of page 3 : 319 

It is not necessary to use FORTRAN floating point notation for a constant in 
the design, but if it is used, the "D" format rather than the "E" format 
should be used for accuracy. 

*Requirement: ace 


ASP, P-Spec 1.3 


ASP P-Spec 2.3, page 4 307 

Problem: Even though a check is being made for all accelerations being equal, 
it is still required that a check be made for a negative argument for the 
square root, as all equals may not be the only case with a roundoff problem. 

*Requirement: spec, Reference: introduction, exception handling 


GSP, P-Spec 1.4 


GSP, P-Spec 1.4, top of page 3 308 

"if ((G COUNTER(I) & 0x8000 = 1)" 

Problem: The intent here is to determine whether G COUNTER(I) has a negative 
sign. The partial statement above will not work because if the sign is 
negative, the resulting "anded" value is not equal to 1. 

*Requirement: spec, ace 
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Individual Inspection Preparation Log #1 (Page 7) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

TDLRSP, P-Spec 1.5 

TDLRSP, P-Spec 1.5, page 4, top of page and bottom of page also: 320 

"do (for each radar beam i)" 

Problem: The design has not explicitly stated the number of radar beams. 

*Requirement: comp, nonamb 

TDLRSP, P-Spec 1.5, page 4, top of page: 321 

Problem: The equation for elapsedtime is not given in the pseudocode itself, but only in a 
comment. 

*Requirement: comp, nonamb 

TDLRSP, P-Spec 1.5, page 4, middle of page: 

"if (elapsed time >= TDLRLOCKTIME 
tdlr_state(i)= 0 /*set unlocked */ 

FRAMEBEAMUNLOCKED(i) = FRAMECO 

else /* the sensor has not recovered */ 

TDLR STATE(i) = 0 /*set unlocked */ 
endif 
endif 

else /* the sensor measurement != 0 */ 

if (TDLR STATE(i) == 1 /* beam was locked */ 

TDLR STATE(i) = 1 /* set locked */ 

else /* beam was unlocked */ 

if (elapsed time >= TDLR LOCK TIME) 

TDLR STATE(i) = 1 /* set locked */ 

else /* the sensor has not recovered */ 

TDLR STATE(i) = 0 /* set unlocked */ 

Problem 1 : Line #2 is not traceable to any requirement 
Problem 2: Lines 4 and 5 are not traceable to any requirement 
Problem 3: Line 10 is not traceable to any requirement 
Problem 4: Lines 14 and 15 are not traceable to any requirement 

*Requirement: spec 

TDLRSP, P-Spec 1.5, top of page 5 309 

The setting of the off-diagonal elements of KMATRIX to zero is not a requirement in the 
specification, (the spec may require a formal mod to make this unambiguous). 

*Requirement: trace 


322 


LINE NUMBER 
1 
2 


UNTER 

4 

5 

6 
7 


9 

10 
11 


12 

13 

14 

15 
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Individual Inspection Preparation Log #1 (Page 8) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

TDLRSP, P-Spec 1.5, Equation for pbvY : 323 

Problem 1: Page 5, comments at bottom of page: 

In the equation for "b", the operator in front of the term b(4) is incorrect. 

Problem 2: Page 7, in case #15: 

In the equation for "pbvY", the operator in front of the term b(4) is 
incorrect. 

*Requirement: ace, spec 

TDLRSP, P-Spec 1.5 324 

"where cos represents the cosine function" 

Problem: This statement has not been marked as a comment. 

*Requirement: nonamb 


TDSP, P-Spec 1.6 


TSP, P-Spec 1.7 


TSP, P-Spec 1.7, middle of page 2 326 

"Implementation note, if M1=M2 a divide by zero exception must be handled. 

Problem 1 : The divide-by-zero exception handling should happen prior to the 
divide. 

*Requirement: spec 

Problem 2: (nnp)While this cannot really be considered an error, the syntax 
and content for this exception is not presented in a consistent manner with 
the rest of the exception handling in this design. This looks like a comment 
but is actually pseudocode. 

*Requirement: con 

TSP P-Spec 2.11, middle of page 3 314 

In the calculation for lower-parabolic-function, there is a division by 
(M4 - M3), but there is no provision for a check for divide-by zero in case 
M4 = M3. 

*Requirement: spec, INTRODUCTION, Exception Handling 

TSP P-Spec 2.11, 1 Oth line from bottom of page 3 313 

"y = 4*p..." 

Problem: "4*p" is not correct 
*Requirement: ace, nonamb 
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Individual Inspection Preparation Log #1 (Page 9) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

GP, P-Spec 2.2 

GP, P-Spec 2.2, INPUT/OUTPUT section: 328 

TEINTEGRAL is not an input to this process. 

*Requirement: ace, spec 

GP, P-Spec 2.2, middle of page 4 through middle of page 5: 330 

Application of Runge-Kutte: 

In the text which describes the method for calculating attitude, velocity, and altitude, beginning 
with "A five step implentation of the RK method..." and ending with step 5, the comments are not 
clearly delineated from the pseudocode. 

*Requirement: nonamb, comp, spec 

GP, P-Spec 2.2, middle of page 4 through middle of page 5: 331 

Application of Runge-Kutte: 

Problem: In general, the pseudocode given is not directly translatable into souce code. More 
specifically: In each of the four parts labeled "A)": 

Problem 1 : It is not stated for any of the three derivatives which history values are to be used 
for the "sensor" variables. 

Problem 2: In the case of the derivative of the velocity, it is not stated which values are to be 
used for the attitude. 

Problem 3 : In the case of the derivative of the altitude, it is not stated which values are to be 
used for the attitude or for the velocity. 

Problem 4: The equations for the derivatives have not been included in the pseudocode. 

GP, P-Spec 2.2 303 

Problem: GPROTATION may not be used as an input to GP, yet it appears in the design's 
equations for the derivatives of GP ATTITUDE and GP VELOCITY. (see specification, page 
130, under Notation) 

*Requirement: req, comp 

GP, P-Spec 2.2, bottom of page 5: 332 

In the setting of the GP ROTATION matrix, the wrong history subscript is being used for the 
G ROTATION elements. 

*Requirement: spec, ace 

GP, P-Spec 2.2, second line of page 7, and fourth line of page 10:: 333 

In each case there is no check for a negative argument before the square root is taken. 
*Requirement: spec 
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Individual Inspection Preparation Log #1 (Page 10) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 

GP, P-Spec 2.2, page 7 through 8: 334 

(nnp)In several places " i = 101 " is used as a "coding" method for exiting the loop. While this 
is 

not an error, it would be adequate (and preferable) in the design to state "exit the loop". 

GP, P-Spec 2.2, page 7 and page 8: 335 

In three separate places there is a check for divide-by-zero. In each case 
if there is an exception, the text "COMPUTATION OF OPTIMAL VELOCITY" is 
produced, which is not a requirement in the specification. 

*Requirement: trace 

GP, P-Spec 2.2, middle of page 8: 336 

"if ((CONTOURALTITUDE = 0) .or. (index == 1 00)) then 

Problem 1 : CONTOUR ALTITUDE is a vector but has no subscript. 

Problem 2: "index" is undefined. 

*Requirement: nonamb, comp, ace, spec 

GP, P-Spec 2.2, bottom of page 10: 338 

(nnp)The designer stated at the overview that "END GCS would not be 
implemented". If that is the case, it should not be set inside a process. 

*Requirement: trans, trace 


AECLP, P-Spec 2.1 


AECLP P-Spec 2.1, top of page 4: 301 

"if (FRAMECOUNTER - FRAMEENGINESIGNITED * DELTAT <... {4} " 


"if (FRAME COUNTER - FRAME ENGINES IGNITED * DELTA T >=... {4} " 

Problem: In each of these statements, assuming the FORTRAN precedence rules, 
the order of execution of the operators is not correct. 

*Requirement: ace, req 

AECLP P-Spec 2.1, middle of page 7: 302 

"yaw error limit = -GQ(CL) * GP_ROTATION(l,2) + ..." 

Problem: This partial statement contains an incorrect term. 

*Requirement: ace, req 

AECLP P-Spec 2.1, top of page 9: 304 

"let e = 2.718 " 

Problem: This value given for e is not correct (it is not really necessary to define e). 
*Requirement: ace 


C-86 



Individual Inspection Preparation Log #1 (Page 11) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 


RECLP, P-Spec 3,4 


RECLP P-Spec 2.8, pages 3&4, deriving roll engine command: 3 1 1 

Problem: There are three specific cases for which the value set for RECMD 
is not correct. These cases are as follows: (LET P = G_ROTATION(1,0) 

1. THETA = 0 and P > P2 and P <= P4 

2. THETA = 0 and P <= P2 and P > PI 

3. THETA < 0 and THETA >= -THETA 1 and P < -P2 

4. THETA < 0 and THETA >= -THETA 1 and P = -P2 
*Requirement: spec, ace 

RECLP P-Spec 2.8, page 4, middle of page, deriving roll engine command: 312 

"else if (THETA >= THETA2) then {3 } " 

Problem: The sign of THETA2 is not correct. 

*Requirement: spec, ace 


CRCP, P-Spec 3.3 


CRCP, P-Spec 3.3, page 1, top of page 339 

"log*l released = 1" 

Problem: "released" is not used in this process. 

Problem: (nnp) While not an error, the declaration of local constants is not 
consistent with the syntax in the rest of the design. 

*Requirement: trace, con 


CRCP, P-Spec 3.3, page 1, middle of page 340 

The three format statements are not needed (see limits section). 

*Requirement: trace 

CRCP, P-Spec 3.3, page 1, bottom of page 341 

"IF (CHUTE RELEASED = not released)" 

(nnp)Not an error, but why not used "chute attached" for consistency? 

*Requirement: con 
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Individual Inspection Preparation Log #1 (Page 12) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 


CP 


CP, P-Spec 2.4 

Problem with presentation of ere table (for purposes of verification by 
inspectors) (designer may include algorithm for table) 

CP, P-Spec 2.4, PAGE 7 
"DATA_PACKET.data.sp.k_matrix(3) =..." 

Problem: first subscript for K MATIRX is incorrect 

CP, P-Spec 2.4 
Ambiguitie 

1. Page 5, "var data_packet: 

= PACKET" 


2. Page 9: 

1 . Is table to be read column first or row first? 

2. How many bits are in the CRC? 

3. In loops for bytes, start with first or last byte? ie, definition of 
next_byte? 

CP, P-Spec 2.4 
Page 9 

"index = ere XOR nextbyte" 

Problem: Design has not stated that only the low-order byte of ere is to be 
used. 


GCS_SIM RENDEZVOUS, P-Specs 1.1, 2.1, and 3.1 


GC S SIM RENDEZ V OUS , P-Specs 1.1, 2.1, and 3.1 342 

In the body of the P-Spec is the statement ", it is not our responsibility." 
This is not an appropriate statement to be inside a P-Spec, since the 
function of a P-Spec is merely to state the transformation from the inputs to 
the outputs. 

*Requirement: trace 



Individual Inspection Preparation Log #1 (Page 13) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 


DATA DICTIONARY 

Four Global Data Stores and Ordering with "+" Notation 345 

Hatley (page 101) states that the "+" notation "does not imply order. If 
ordering is required, it is specified by a comment in the dictionary or 
PSPEC"; therefore, for the global data stores, there should be some such 
explicit statement. 

Data Conditions (not an error) 346 

All variables in the data dictionary that are listed with attribute of "data 
condition" could be changed to "data" (with the exception of GPPHASE and 
CHUTERELEASED). 

Notation 347 

Hexadecimal notation is used in, for example, COMM SYNC PATTERN, but the 
syntax for the notation is given inside pspecs, for example, TDSP. The 
notation should be given in some central place, such as, for example, the 
data dictionary or the introduction. 

ENDGCS 348 

This is a primitive data element but has no description at all. 

G1 349 

The units are not correct. 

GPGSIN 350 

This group flow includes TE INTEGRAL which is not an input to GP. 

KMATRIX 351 

The Accuracy is incorrect. 

TDLRANGLES 352 

In the range, the value PI/2 should not be included. 
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Individual Inspection Preparation Log #1 (Page 14) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 


Typographic Errors 

GSP, page 1, comments at bottom of page: 

"diminsion" should be "dimension" 

GSP, page 3, comment at top of page: 

"hexidecimal" should be "hexadecimal" 

ASP, page 3: "hexidecimal" should be "hexadecimal" 

TDSP, page 1 : In comment near bottom of page, "hexidecimal" should be 
"hexadecimal" 

GP, bottom of page 8 to top of page 9 
A line has been split in two. 

GP, bottom of page 9 
Should "=<" be "<=" ? 

GP, page 8, in two different comments: 

"Exapolation" and "Exapolate" should be "Extrapolation" and "Extrapolate" 

ASP, page 4, comment at top of page: 

"seperate" should be "separate" 

Notes on high-level design, page 1 : 

Third paragraph: "have to input or output" should be "have no input or 
output" 

Fourth paragraph, last sentence: "with of off_page" should be "with off-page" 
Last paragraph: should "deficients" be "deficiencies"? 

Data Dictionary 
G2, in the units is "degree\*" 

TEDROP, the last word of the description, namely "intersected" was cut off. 
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Individual Inspection Preparation Log #1 (Page 15) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 


Suggestions for the Future 

It would be helpful if the entire design document were numbered sequentially 
from beginning to end. 

Constants used for limit checking make modification difficult and error- 
prone. 

Can we add something to the standards to force the designer to be explicit 
about what is a comment and what is actual pseudocode/structured English? 

Can we add something to the standards to force the designer to use very 
specific non-ambiguous pseudocode syntax? 

Require that a Teamwork Balance Report (with no errors) be included as part 
of the design. 
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Individual Inspection Preparation Log #1 (Page 16) 

Name: Bernice Becher Date Log Submitted: July 12, 1994 

Implementation: Pluto Date of Inspection: July 7,1994 

Role: Inspector 

Defects/Clarity Problems/Concems 


*Requirement: Accuracy (Reference: DO-178B 6.3.2b). 

2 

*Requirement: Nonambiguity (Reference: DO-178B 11.0a). 

3 

*Requirement: Follow a particular design method (References: Software 
Development Standards, "Software Design Standards", "Design Methods, Rules, 
and Tools", "...using the structured analysis ...by Hatley and Pirbhai 
or...", and "Design Documentation", "...document should follow. ..GCS 
specification or the Hatley book...") 

4 

*Requirement: Consistency (DO-178B 5.2.2a, 6.3.2b, and 11. Od) 

5 

*Requirement: Traceability (References: DO-178B 5.2.2a, 5.5b, 6.1b, 6.2a, 
6.3.2a, and 1 1 .Of) 

6 

*Requirement: Translatability to source code (Reference: Software 
Development Standards, Software Design Standards, "The low level 
requirements should be directly translatable into source code, with no 
further decomposition required.") 

8 

*Requirement: Completeness (Reference: DO-178B 11.0b) 

10 

* Requirement: Fullfillment of requirements in Software Requirements 
document (References: DO-178B 6.3.2a and 11.10a) 

11 

* Requirement: Fullfillment of requirements in Software Requirements 
document (References: DO-178B 6.3.2a and 11.10a) 

**Software Requirements 2.2 with Mods 1-26 Reference: Introduction, 
Exception Handling, Upper or Lower Limit Exceeded 

*Requirement: ace 
*Requirement: nonamb 
*Requirement: des 
*Requirement: con 
*Requirement: trace 
*Requirement: trans 
*Requirement: comp 
*Requirement: spec 
*Requirement: modif 
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Review Log from Verification Analyst 


Pluto Individual Inspection Log 

Inspector: Patrick Quach 
Date: July 11, 1994 

The following is a list of deficiencies or possible deficiencies found in the Pluto design 
document. The comments are grouped under the heading of the P-Spec. or configuration item to 
which they pertain. No deficiencies were discovered in any DFD's or PAT's. 

ARSP (P-Spec 1.2) 


1. I/O Section 

FRAMECOUNTER is an unnecessary input to ARSP because it is not used in the P- 
Spec. It is, however, listed as an input in the Requirements Document. This may be a 
left over from the Spec. Mod. 2. 3-3. 3 

2. Limits checking for ARALTITUDE 

Question: Does the range checking have to be performed on AR ALTITUDE before 
using it in the Divided Difference Method. It is a real* 8 from SENSOROUTPUT data 
store. 

CITATION: Spec. — Exception Condition (pg. 16) 

ASP (P-Spec 1.3) 

3. Limits checking for AACCELERATION 

Question: Does the range checking have to be performed on A ACCELERATION before 
it is used to calculate the mean and standard deviation for each axis. It is a real*8 from 
SENSOR OUTPUT data store. 

CITATION: Spec. — Exception Condition (pg. 16) 


TDLRSP (P-Snec 1.5 ) 

4. Concerning the set of IF statements for determining radar beam states (pg. 4) 

The design meets all the requirements but has extra branches that are not specified in the 
Requirements. However, these branches are innocuous and do not change any values. It 
may not be worth the risk to alter the design since it may introduce some logic errors. 
CITATION: Spec — Use of Tables (pg. 15) 

5. Concerning the table for setting KMATRIX (pg. 5-7) 

The table uses the X, Y, Z indexes for the elements of K MATRIX while the case 
statement uses the actual numerical indexes. It may be useful to clarify this in the text of 
the explanation. 

CITATION: 178B — Non-Ambiguity (pg. 47 11. OA) 

6. Divide by zero check(pg. 8) 

Question: In step 3D, should a divide by zero check ( on the COS[TDLR_ANGLES] ) be 
performed before TDLR VELOCITY is computed. 
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TSP (P-Snec 1.7) 


7. Lower parabolic function (pg. 3): 

There appears to be a typo in the substitution of "h" into the parabolic equation. Either 
there is an extra set of paren. or the sign after the M3 should be a "+" 

CITATION: 178B — Non- Ambiguity (pg. 47 1 1.0A) 

GP (P-Spec 2.2) 


8. GP Algorithm notes (pg. 1) 

Typo on first word of second paragraph. 

9. Setting up GPROTATION (pg. 5): 

Question: Should the most recent values for GROTATION be used to build 
GPROTATION. 

10. The Else branch for "CONTOUR ALTITUDE(i) < cur altitude" (pg. 8): 

The index is missing from the first part of the IF condition. It should be 
"CONTOURALTITUDE(i)". 

CITATION: 178B — Non- Ambiguity (pg. 47 1 1.0A) 

RECLP (P-Spec 3.4) 

1 1 . The If statement for determining roll engine intensity & direction (pg. 4) 

Typo in the case where: 

THETA >= -THETA & G ROTATION < -P2, 
the value of RE CMD should be: 

RECMD = 6 + 0. 

CITATION: 178B — Non- Ambiguity (pg. 47 1 1.0A) 

AECLP (P-Spec 3.2) 


12. Divide-by-zero check (pg. 6) 

Question: Why is there an extra Divide-by-zero check in the yaw error limit calculation. 
The check was performed previously in the pitch error limit calculation? 

13. Yawerrorlimit equation (pg. 7) 

Typo in the yaw error limit equation; the first gain should be "GR" instead of "GQ". 
CITATION: Compliance (pg. 27 6.3.2a) 

14. Processing step enumeration (pg. 7-10) 

The enumeration of step "2C" on the middle of page 7 duplicates the previous 
numbering. This step should be "2D", Subsequent steps are also off by 1 letter. 
CITATION: 1 78B — Non- Ambiguity (pg. 47 1 1 .0A) 

15. The value of "e" (pg. 9) 

Typo in the value of "e" e = 2.718281828459045235360 

CITATION: 178B — Accuracy (pg. 27 6.3.2b) 

16. Concerning setting of AE CMD from INTERNAL CMD (pg. 11) 

Typo in second branch of all 3 "If' statements; should read: "(INTERNAL_CMD(i) 

<= 1)" 

CITATION: 178B — Non-Ambiguity (pg. 27 6.3.2b) 
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CRCP (P-Spec 3.3) 


17. Limit checking (pg. 1) 

Limits checking is not necessary for CHUTERELEASED and AETEMP. 

CITATION: Spec. — Exception Condition (pg. 16) 

18. Local variable definition (pg. 1) 

Defining the local variable "hot" as an "int*2" is more accurate but does not agree with the 
Requirements. 

CITATION: 178B — Non-Ambiguity (pg. 27 6.3.2b). See also Data Dictionary citation for 
AETEMP 

19. Concerning the variable assignment (pg. 1) 

Typo in assignment for CHUTE RELEASED. 

CITATION: 178B — Non-Ambiguity (pg. 27 6.3.2b) 

Data Dictionary 

Open Issue: The Specification does not give the required accuracy for many data elements. Hence this 

field is also "TBD" in many instances in the Design Data Dictionary. Will this be determined 
before coding, before testing, or left to the programmer and tester's discretion? 

CITATION: 178B — Verifiability (pg. 27 6.3. Id) 

AE TEMP This element is specified as a "LOGICAL- 1". In general, logical variables can have only 2 
values, but this one has more. An enumerated type is more correct. The Requirements 
Data Dictionary also has this defined as a LOGICAL- 1 
CITATION: 178B — Non-Ambiguity (pg. 27 6.3.1b & 6.3.2b) 

CL Question: Should the range for this data element correspond with the TeamWork usage? 

CITATION: 178B — Non-Ambiguity (pg. 27 6.3.2b) 

CONTOUR CROSSED Typo in DESCRIPTION field: "velocity altitude" should be "velocity-contour" 
CITATION: 178B — Non-Ambiguity (pg. 27 6.3.2b) 

DROP HEIGHT Typo in ACCURACY field: extra period 

G1 Typo in UNITS field: should be "(meters/sec A 2)/(degree_C)" 

CITATION: Compliance (pg. 27 6.3.2a) 

G2 Typo in UNITS field: should be "(meters/sec A 2)/degree_C A 2" 

CITATION: Compliance (pg. 27 6.3.2a) 

GVEI Typo in UNITS field: unit should be "/sec A 2" 

CITATION: Compliance (pg. 27 6.3.2a) 

K MATRIX Typo in ACCURACY field: does not agree with Specification. Spec, has "N/A". 
CITATION: Compliance (pg. 27 6.3.2a) 

TDLR ANGLES Typo in DESCRIPTION: the "y" should be "gamma" 

CITATION: 178B — Non-Ambiguity (pg. 27 6.3.2b) 

Typo in RANGE field: PI/2 should be excluded from the range according to the Spec. 

CITATION: Compliance (pg. 27 6.3.2a) 

TE DROP Format error in DESCRIPTION field: missing last part of explanation 
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C.3 Pluto Code Review 


Attendees: Kelly Hayhurst (SQA representative/Moderator) 

Patrick Quach (Verification Analyst/Recorder, Inspector) 
Philip Morris (Programmer/Reader, Inspector) 

Bernice Becher (System Analyst/Inspector) 

C.3.1 Review Notes from Code Review 


Pluto Code Review 


Session 1: 11/16/94 9:30 a.m. - 11:30 p.m. 

Reviewed Comments on Design before examining Code 

Design Issues 

B-l — “RETURNS” should be removed from the design 

B- 1 8 — need to correct statement about data and control flows 

Need to include balance report as part of design documentation 

B-2, B-3W — P-Spec ASP: problem with computing standard deviation and comments about it 
— > Related to Spec Mod 2. 3-4.2 

B-l 5 — P-Spec CP: problem with type of SUBFRAMET 

B-l 8 — P-Spec CP: problem with GP ROTATION and GP VELOCITY — they need subscripts 
P-Spec CP: typos, need ] instead of) on page 7 of data packet stuff 

B-l 7 - P-Spec CP: need to define specify order for next byte (not a code problem) 

B-7 — P-Spec GP: problem with equations of att_k2, vel_k2, alt_k2 and ... att_k3, vel_k3, alt_k3 
— > Problem is also in Code — see B-42 in code review log 

B-8 — P-Spec GP: extra range check after END P SPEC 

B-l 1, B-4, P-12 — P-Spec GP: need to comment a “where” statement 

B-6 — Data Dictionary: problem with attribute of “data condition” for several variables (not a 
code problem) 

B-l 4 — Data Dictionary: CHUTE RELEASED — should be in the EXTERNAL data store 
— > Related to Spec Mod 2.3-4 (should have been corrected in PR #20) 

END OF SESSION 1 — - 
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Session 2: 11/16/94 1:00 p.m. - 3:00 p.m. 

Code Issues: 

B-36 — ADD TO DEVELOPMENT STANDARDS: require P-Spec numbers in part of module 
headers 

B-35, B-36 — floating point constants should all be double precision to avoid precision problems 

B-56 — DEVELOPMENT STANDARDS Bernice would like the list of arguments in the module 
header to include whether each argument is on input, output, or both 

B-58 — might want to consider deleting the requirement to note configuration date in the 
Development Standards 

B-30 — EXTERNAL. FOR: problem with clp data t — data type is incorrect 
~> SEE SPEC MOD 2.3-2 ? 

NOTE: Want to require that inspection logs have all items uniquely ordered (to make notes 
easier to follow) 

B-32 — PLUTO. FOR — check for termination should be done after subframe 3 — not subframe 2 
— > see Spec Mod 2.3-2. 1 

B-33 — PLUTO. FOR: “go to 100” — no unconditional gotos (this one is not justified) 

B-34 — AECLP.FOR — need to check for divide-by-zero for OMEGA (both design and code need 
change) 

NOTE: Require that listing file be turned in for review sessions 

B-40 — CRC16.FOR: generator polynomial is not correct — chould also note that the bits are 
reversed 

B-57 — CRC16.FOR: in module header — should say that it is returning checksum 

B-41 — GP: when calling multvel — should be sending vel kl ... not att kl 

B-43 — GP: the last argument for deriv vel is incorrect 

B-44 — GP: unconditional go tos — not justified 

B-45, P-11 — GP: problem with relational operator — “.GE.” is not correct (design is correct) 
Need range check for VELOCITY ERROR in code (design is correct) 

B-46, B-50 — go to is okay — but need safety net — same as in TDLRSP 

B-47 — problem with EQUIVALENCE statement and the variables pv, qv, rv — problem is in 
both DERIV ATT and DERIV VEL 
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P-8 — MULT_ATT: problem in matrix multiplication 

B-5 1 — TDLRSP: missing go to statement 

P-6 - GSP: “counter” is mistyped - it should be an integer 

B-52 - LOWER PARABOLIC FUNCTION.FOR - problem in calculation of 

LO WERP ARAB O LI C_ FUN C T I O N — term “M3 + half slope” is incorrect (design is 
okay) 

B-53 — UPPERPARABOLICFUNCTION: problem in calculation of upper parabolic function 

B-55 — UTIFITY.FOR: problem with format statement 30 

P-2 - CONSTANTS. FOR - AE TEMP is mistyped - 
— > See Spec Mod 
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C.3.2 Review Logs from Code Review 
Review Log from System Analyst 

11/15/94 
11/16/94 


PLUTO DESIGN LOG III 
GENERAL ISSUES 


Individual Inspection Preparation Log #1 (Page 1) 

Name: Bernice Becher Date Log Submitted; 

Implementation: Pluto Date of Inspection 

Role: Inspector 

Defects/Clarity Problems/Concems 


1 "Return" in P-Specs 

Several of the P-Specs contain a "return" before the "END PSPEC". Since "return" is 
purely a coding function, it is not appropriate in a P-Spec and in addition accomplishes 
no function with respect to how the inputs of the process are converted to its outputs. 
The processes which contain "return" are: 

+CRCP (added since design review but not mentioned in action item 16) 
+AECLP (added since design review but not mentioned in action item 16) 
*ASP 

*ARSP *TDLRSP 
*GSP *TDSP 

*RECLP *TSP 

*GP (4 separate returns) 

*=remains in from before design review 
+=was added since design review 
*Requirement: traceability 

INTRODUCTION 


13N It is difficult to refer to text because the pages of the introduction are not numbered. 
*Requirement: modifiability 

5W Section 1.3, Design Syntax Specifications, fourth paragraph. 

It does not seem that the indirection symbol and Modula-2 record syntax were really 
needed, when the FORTRAN record structure syntax would have been adequate (and in 
fact was used in the code). It seems that the indirection added an unnecessary level of 
complication in the design, and was not used at all in the code. 

*Requirement: traceability 

18 Section 2.2, Data and Control Flows, fifth paragraph: 

"...the consequence of this action will result in approximately 80 data flows requiring off- 
page connections..." 
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Individual Inspection Preparation Log #1 (Page 2) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 

It is not clear that this statement is entirely correct. It would seem that approximately 18 
group-flows would be required, and they would not need to be off-page connectors. 
Perhaps a statement saying that the number of data flows would increase would be more 
accurate. 

*Requirement: accuracy 

STRUCTURED ANALYSIS CHARTS 


9 PATO 

• There is an empty input cell under the heading GPPHASE. There should either be 
an entry in this cell or some explanation as to the meaning of an empty cell. 
*Requirement: nonambiguity 

• There is no explanation for what will happen in terms of activation when GP PHASE 
has not yet been defined, which is the case before the first activation of 
GCSSIMRENDEZ V OUS. 

*Requirement: nonambiguity 

• The statement " "GP PHASE" is initialized to "1" during initialization" is not correct. 
It is possible that it might be initialized to any value from 1 to 5. The specification states 
that it will be initialized but does not state the initial value. 

*Requirement: accuracy 

191 Teamwork Balancing Report 

Should a balancing report be included in the design document? 

*Requirement: completeness 


P-SPECS 

ASP(1.3) 


2 Page 4, comment at bottom of page: 

"identical values" should be "identical or nearly identical values" 

*Requirement: accuracy 
*Requirement: completeness 

3W Calculation of standard deviation (sd) 

Design, Page 4, bottom, and page 5: : 

The specification has been modified (mod 2. 3-4.2) to give a formula for the standard 
deviation which cannot yield a negative square root. This design does not use the new 
formula and hence can produce a negative square root, for which a check is being 
made. The negative square root problem could be eliminated and there would be no 
need for a square root check if the formula in the Specification were used. Is the design 
OK as stands? 

(affected code: lines 831 through 837 
*Requirement: specification 
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Individual Inspection Preparation Log #1 (Page 3) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 

CP (1.8) 

15 Page 5, bottom of page: (not a code problem) 

"type subframet = (subframet, gpdatat, clp data t)" 

Problem: "subframe t" ,on the right hand side of the assignment, is incorrect. 
*Requirement: accuracy 
*Requirement: specification 

18 Page 8, top 

In each of the assignment statements for GP ROTATION and GPVELOCITY, there is 
no subscript on the left hand side. 

*Requirement: nonambiguity 
*Requirement: specification 

17 Page 9, bottom: 

"do for each byte in the message next byte" 

"next_byte" is ambiguous in that it doesn't specify the order, i.e., first-to-last byte or vice 
versa, (not a code problem) (was #402) 

*Requirement: nonambiguity 


GP(2.2) 

7 Page 6, top : 

In each of the equations for att_k2, vel_k2, alt_k2, att_k3, vel_k3, and alt_k3, the right 
parenthesis preceding the term "/2" is not in the correct place., and thus the attitude, 
velocity, and altitude arguments for the derivative routines are not correct. 
*Requirement: accuracy 
*Requirement: specification 

8 Page 14, middle 

A range check for altitude follows "END P SPEC" but has already been done where 
needed. 

*Requirement: translatability 
101 Page 8, top and page 11, middle: 

Is check for negative square root really necessary, given that a valid GP ALTITUDE(O) 
will be positive, and that GP ALTITUDE(O) has been checked earlier and then not 
changed. 
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Individual Inspection Preparation Log #1 (Page 4) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 


11 Page 13, middle: 

The following statements are comments and should be designated as such. In addition, 
there is some confusion because they appear in the middle of an equation. 

"where 
pv :=... 

rv :=... " 

*Requirement: nonambiguity 


TDLRSP(1.5) 


4 Page 7, bottom (previous #324): 

"where cos represents the cosine function" 

Problem: This statement has not been marked as a comment. 
*Requirement: nonambiguity 


DATA DICTIONARY 

6 (previous number: 346) (not a code problem) 

There are several elements in the data dictionary whose ATTRIBUTE is listed as "data 
condition". In fact, in the SA/SD charts, none of these is ever used as anything except a 
data flow. These elements are: 

AESWITCH 

AETEMP 

CONTOURCROSSED 
RESWITCH 
TDSENSED 
TDLRSTATE 
*Requirement: accuracy 
*Requirement: consistency 
*Requirement: nonambiguity 

14 Element CHUTERELEASED (not a code problem) 

The DATA STORE section says GUIDANCESTATE, but according to Formal 
Modification 3. 2.4-4, it should be EXTERNAL. Problem Report 20 states this has been 
changed, but it hasn't been. 

This oversight causes one to wonder why there is not some type of error produced by 
Teamwork, because now all the DFDs show CHUTE RELEASED coming from and 
going to EXTERNAL, while the data dictionary states that it is in GUIDANCE STATE. 
*Requirement: accuracy 
*Requirement: consistency 
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Individual Inspection Preparation Log #1 (Page 5) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 


TYPOS 

INTRODUCTION, Section 1.3, fourth paragraph: 

"previous chosen to signify" should be "previously chosen to signify" 

ARSP (1.2), page 2, bottom 

"recieved" should be "received" 

DATA DICTIONARY 

COMMSYNCPATTERN 

In the RANGE, "hexidecimal" should be "hexadecimal" 

TDSP, page 1 

"hexidecimal" should be "hexadecimal" 

Introduction, Section 2.3, Module Description, discussion about GP VELOCITY: 

"oincide" should be "coincide" 

Introduction, Section 2.3, Module Description, AECLP equations: 

The entire discussion uses a Greek capital symbol for X double dot (acceleration), while 
the very last equation for Q reverts to the small x for acceleration. 

ARSP, page 2, bottom: 

"recieved" should be "received" 

CP, page 2: 

In comments, "consist of' should be "consists of' 

CP, page 3 : 

Comment which gives total no of bytes for sensor processing, "127" should be "129" 

CP, page 4: 

In comments, "returns and integer" should be "returns an integer" 

GP, page 9: 

"Exapolation" should be ""Extrapolation" in two places 
"Exapolate" should be "Extrapolate" 

GP, page 10: 

"range check the current altitude" should be "range check the VELOCITY ERROR" 
GP, page 1 1 

" GP ALTITUDE [0 ] =<" should be ”GP_ALTITUDE[0] <=" for consistency 
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Individual Inspection Preparation Log #1 (Page 1) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 

PLUTO CODE LOG I 

GENERAL ISSUES 


36 All Modules 

The correspondence between P-Specification number in the design and FORTRAN modules 
is not given 

*Requirement: nonambiguity 
*Requirement: traceability 
*Requirement: completeness 

37W Using enumeration of all combinations of subscripts vs. using DO loops: 

In many cases where a rotation is to be done, or where range-checking is to be done for an 
array, loops with variable indices are not used, but rather a separate assignment statement is 
given for each element of the array. This cannot be considered an error; however, in the code 
it is quite error-prone, difficult to verify, difficult to maintain in the case of changes to the 
requirements, and involves many more lines of code than would otherwise be necessary, (see 
e.g., GP, lines 728-888; TDLRSP, lines 711-764) 

*Requirement: verifiability 
*Requirement: modifiability 


35 W Constants 

Many of the floating point constants used in the code have not been written in a format which 
explicitly declares them as double precision constants. Whether this will cause a loss of 
precision seems to depend on other factors such as the use of parentheses and the order in 
which the operations are done. In some cases, it is clear from experience that there is 
definitely a problem, and in some cases, there is the potential for a problem. Also, many of 
the constants in floating point expressions are written without decimal points (which probably 
will not cause a problem). 

Some particular cases noticed are: 

AECLP.FOR: 

None of the constants from lines 974 through 978 is explicitly declared as double 
precision. The one which is specifically in question in terms of possible precision 
problems is "0.5". 

ASP.FOR 

Lines 818 and 837, constant is 3.0 
GP.FOR 

Lines 995, 1007, and 1017, constant is 6.0 
Lines 993, 1006, 1017, constant is 2.0 
Line 1086, constant is 1000.0 
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Individual Inspection Preparation Log #1 (Page 2) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 


TDLRSP.FOR 

Lines 925, 935, 948, 959, etc., constant is 2.0 
TSP.FOR 

Lines 738 AND 749, constant is 0.15 

LOWERPARABOLICFUNCTION.FOR 
Line 178, constant is 2.0 

UPPER PARABOLIC FUNCTION.FOR 
Line 178, constant is 2.0 

CONSTANTS.DAT 
All of the upper and lower bounds. 

K$THETA$UB and K$THETA$LB 
*Requirement: accuracy 
*Requirement: nonambiguity 
*Requirement: specification 

56H Modules with Arguments: 

The Software Standards state that each module should list its arguments, and the Pluto 
modules do this. It would be very helpful if a comment would state for each argument 
whether it is an input, output or both. The modules in question are: 

CRC16, DERIV ATT, DERIV VEL, DERIV ALT, MULT ATT, MULT VEL, 
(AVG ATT), (AVG VEL), RANGE CHECK, N EG_V ALUE CHECK, and 
ZERO CHECK. 

*Requirement: nonambiguity 
*Requirement: completeness 


58 All Modules 

The Software Standards state that each module header should include the "DATE FIRST 
SUBMITTED FOR CONFIGURATION MANAGEMENT". The Pluto modules do not 
appear to have this date, as 15-Sep-1994 is not the configuration management date, which 
apparently is 26-Sep-1994. 

*Requirement: Software Standards 


SPECIFIC PROBLEMS IN MODULES 


30 EXTERNAL. FOR 

Under "structure /clp_data_t/", the data type for ae_temp is incorrect. 
*Requirement: accuracy 
*Requirement: consistency 
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Individual Inspection Preparation Log #1 (Page 3) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 


32 PLUTO. FOR 

The check for whether to terminate is being done at the end of the second subframe. 
Formal Modification 2.3-2. 1 (Scheduling Section) states that this check should be done 
"immediately after executing the Control Law Processing subframe". 

*Requirement: specification 

331 PLUTO. FOR 

The statement near the end of the loop, namely "go to 100" is an unconditional GO TO 
which is not permitted according to the Software Standards. 

*Requirement: Software Standards 

34 AECLP.FOR, between lines 895 and 897: 

A divide-by-zero check is required for the variable OMEGA. 

*Requirement: specification 


36 ARSP.FOR: 

Line 746: The constant "3E08" is not explicitly double precision and may cause a loss of 
precision. 

*Requirement: specification 
38W CRC.FOR, lines 41 through 136 

Warning: The "data" statements used to initialize the array "table" are very tedious to 
check and the check may be prone to error. 

*Requirement: verifiability 


40 CRC.FOR 

In line 37, the hexadecimal constant given for the CRC-16 generator polynomial is not 
correct. 

*Requirement: accuracy 


57 CRC16 

In the section "Returns", it states that CRC16 is "the CRC-16" of the specified message." 
The "CRC-16 is a bit ambiguous, as it does not explicitly state it is the checksum or error 
code. 

*Requirement: nonambiguity 

41 GP.FOR 

In line 909, the first argument , namely "att kl", is incorrect. 

*Requirement: accuracy 
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Individual Inspection Preparation Log #1 (Page 4) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 


42 GP.FOR 

Lines 921 & 922, 925 & 926, 929, 939 & 940, 943 & 944, and 947 are not correct. 

The subroutines avg att and avg vel are performing an incorrect function, and thus the 
second argument for each derivative call is incorrect. These problems directly relate to 
design problem #7 

*Requirement: accuracy 
*Requirement: traceability 
*Requirement: specification 


43 GP.FOR 

In line 970, the last argument for deriv vel, namely "1", is not correct. 
*Requirement: accuracy 
*Requirement: traceability 
*Requirement: specification 


44 GP.FOR 

Lines 1095, 1114, 1132, 1156, 1203, 1224, and 1256 are unconditional "GO TOs, which 
are prohibited by the Software Standards, and which also differ from the design p-spec. 
*Requirement: Software Standards 

45 GP.FOR 

In line 1178, the relational operator, namely ".GE.", is not correct. 

*Requirement: specification 
*Requirement: accuracy 

461 GP.FOR 

In line 1190, a computed GO TO (which is a variant of unconditional GO TO) is used. Is 
this permitted? 

If it is permitted, then a fall-through statement may be needed in the case where 
GPPHASE is not 1,2, 3, 4, or 5 (in which case no action should be taken as opposed to 
the action for GP PHASE =1). 

*Requirement: accuracy 
*Requirement: traceability 
*Requirement: completeness 
*Requirement: specification 

47 DERIV ATT.FOR 

In lines 72-74, it was intended that the variables pv, qv, and rv will yield the appropriate 
values of G ROTATION. The EQUIVALENCE statements do not accomplish what was 
intended, and therefore, lines 78 through 88 will yield incorrect results. 

*Requirement: accuracy 
*Requirement: specification 
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N ame : 

Implementation 

Role: 


47 DERIVVEL.FOR 

In lines 297-299, it was intended that the variables pv, qv, and rv will yield the 
appropriate values of GROTATION. The EQUIVALENCE statements do not 
accomplish what was intended, and therefore, lines 309, 316, AND 323 will yield 
incorrect results. 

*Requirement: accuracy 
*Requirement: specification 

48 AVGATT.FOR 

This subroutine is performing a function which is not required at all. This problem is 
related to design problem #7 and to code problem #42. 

*Requirement: traceability 

49 AVG VEL.FOR 

This subroutine is performing a function which is not required at all. This problem is 
related to design problem #7 and to code problem #42. 

*Requirement: traceability 

50 TDLRSP.FOR 

In lines 906 through 909, a computed GO TO is used. Is this permitted? 

If it is permitted, then a fall-through statement may needed in the case where the 
computed expression is less than 1 or greater than 15. 

*Requirement: accuracy 
*Requirement: traceability 
*Requirement: completeness 
*Requirement: specification 

51 TDLRSP.FOR 

Following line 963, there is no control statement, and so control will pass to line 967, 
which is not correct. 

*Requirement: accuracy 
*Requirement: traceability 
*Requirement: specification 

52 LOWER PARABOLIC FUNCTION.FOR 

In line 181, the addition operator in the term "...M3 + half slope..." is incorrect. 
*Requirement: accuracy 
*Requirement: specification 

53 UPPER P ARAB OLIC FUN CTION. FOR 

In line 181, both arithmetic operators immediately preceding "half slope" (namely 
and then "+") are incorrect. 

*Requirement: accuracy 
*Requirement: specification 


Individual Inspection Preparation Log #1 (Page 5) 

Bernice Becher Date Log Submitted; 

Pluto Date of Inspection 

Inspector 

Defects/Claritv Problems/ Concerns 
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Individual Inspection Preparation Log #1 (Page 6) 

Name: Bernice Becher Date Log Submitted; 1 1/15/94 

Implementation: Pluto Date of Inspection 1 1/16/94 

Role: Inspector 

Defects/Clarity Problems/Concems 


541 UTILITY.FOR (subroutine RANGECHECK) 

The specification states to "...display the name of the data element in question"... 

In the case of an array, this implementation displays the name of the array, but not the 
subscript(s) of the element in question. Two issues arise: Should it be required that the 
subscripts be displayed? Should the specification be reworded? 

*Requirement: completeness 

55 UTILITY.FOR (subroutines RANGE CHECK, NEG VALUE CHECK, and 
ZEROCHECK) 

In each of the three subroutines, FORMAT statement 30 is missing "x," immediately 
before the "14". 

*Requirement: accuracy 
*Requirement: specification 


TYPOS 


EXTERN AL.FOR 

Heading: "Originial" should be "Original" 

ASP.FOR, page 6, comment on line 970: 

"convertion" should be "conversion" 

GP.FOR, page 9, lines 1 125, 1 141, and 1 149: 
"exapolat..." should be "extrapolat..." 
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Review Log from Verification Analyst 

The following are deficiencies discovered in the Pluto code during the code review process. The 
list is organized by file name and in alphabetical order. 

Reviewer: Cuong C. Quach 


ARSP.FOR 

1) Typo in the comment for step 3 C). .. 
"...mostly recently..." 

Citation: Typographical error. 


CONSTANTS.FOR 

1) AETEMP constants are of incorrect type. Should be Integer*2, not Logical* 1 
Citation: Specification not followed. 


CP.FOR 

1) The variable name "PACKET.DAT A MASK" used to build the packet for subframe 1 is 
typographically different from the same variable used to build the packet for the other two 
subframes. 

Citation: Coding clarity is compromised. 

2) The assignment of the sequence field directly from the MOD intrinsic function is 
erroneous. The MOD function returns a integer quantity but its assigned to a logical. 
Citation: Fortran syntax violated. 


EXTERN AL.FOR 

1) In the structure declaration for "clp data t", the element aetemp is not declared correctly 
according to the Specification. 

Citation: Specification not followed. 


GSP.FOR 

1) The local variable "counter" is typed as a "real*8" when it should be an "integer*2" 
Citation: Specification not followed. 


TDLRSP.FOR 

1) In the table look-up scheme for obtaining beam velocities. The initial computation is offset 
by 1. This would cause selection of beam processing not to agree with the specification. 
Citation: Specification not followed. 
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GP.FOR 

1) In the MULT_ATT subroutine, the second index, of the array element to be multiplied with 
the "factor", is incorrect for the following elements 

att( 1 ,2) 
att(l,3) 
att(2,2) 
att(2,3) 
att(3,2) 
att(3,3) 

Citation: Specification not followed as a result of typographical error. 

2) In the DERIVVEL subroutine, the index for "temp( 1)" is incorrect for the following 
statements: 

temp(l) = TDLR_VELOCITY(2, index) - vel(2) 
temp(l) = TDLR_VELOCITY(3, index) - vel(3) 

Citation: Specification not followed as a result of typographical error. 

3) In GP, at step 4 of the RK-method where vel_k4 is calculated, the wrong history index is 
passed into the "derivvel" derivative routine. 

Citation: Specification not followed as a result of typographical error. 

4) In step 5 - determining if contour-altitude has been crossed, the first if comparison should 
be ".LE." 

Citation: Specification not followed. 


PLUTO.FOR 

1) The third subframe is not executed when GP PHASE =5. this is incorrect. 
Citation: Specification not followed. 
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Appendix D: Test Results Logs for the Pluto Implementation of the Guidance 
and Control Software 

Author: Cuong C. Quach, NASA Langley Research Center 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 
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D.l Pluto Test Case Results Log for AECLP 


TEST CASE 
NAME 


AECLPNROO 1 


AECLPNR002 


AECLPNR003 


AECLPNR004 


AECLPNR005 


AECLPNR006 


AECLPNR007 


AECLPNR008 


AECLPNR009 


AECLPNR010 


AECLPNRO 1 1 


AECLPNR012 


AECLPROO 1 3 


AECLPROO 1 4 


AECLPROO 1 5 


AECLPROO 1 6 


AECLPROO 1 7 


AECLPROO 1 8 


AECLPROO 1 9 


AECLPRO02 0 


AECLPRO02 1 


AECLPRO022 


AECLPRO023 


AECLPRO024 


AECLPRO02 5 


AECLPRO02 6 


AECLPRO02 7 


AECLPRO02 8 


AECLPRO02 9 


AECLPRO03 0 


AECLPRO03 1 


AECLPRO032 


AECLPRO03 3 


AECLPRO034 


AECLPRO03 5 


AECLP RO 036 


EXECUTION 

DATE 


1/5/95 


DATE 

CODE 

FETCHED 


12/21/94 


DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 




















































































AECLPRO03 7 


AECLPRO03 8 


AECLPRO03 9 


AECLPR0 040 


AECLPRO04 1 


AECLPRO042 


AECLPRO043 


AECLPRO044 


AECLPRO045 


AECLPRO046 


AECLPRO04 7 


AECLPRO04 8 


AECLPRO049 


AECLPR0 050 


AECLPRO05 1 


AECLPRO052 


AECLPRO053 


AECLPNR054 


AECLPNR055 


AECLPRO056 


AECLPRO05 7 


AECLPNROO 1 


AECLPNR002 


AECLPNR003 


AECLPNR004 


AECLPNR005 


AECLPNR006 


AECLPNR007 


AECLPNR008 


AECLPNR009 


AECLPNROIO 


AECLPNRO 1 1 


AECLPNR012 


AECLPROO 1 3 


AECLPROO 1 4 


AECLPROO 1 5 


AECLPROO 1 6 


AECLPROO 1 7 


AECLPROO 1 8 


AECLPROO 1 9 


AECLPRO02 0 


AECLP RO 021 



1/18/95 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 


12/21/94 

N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 
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AECLPRO022 
AECLPRO023 
AECLPRO024 
AECLPRO02 5 
AECLPRO026 
AECLPRO02 7 
AECLPRO02 8 
AECLPRO02 9 
AECLPRO03 0 
AECLPRO03 1 
AECLPRO032 
AECLPRO03 3 
AECLPRO034 
AECLPRO03 5 
AECLPRO03 6 
AECLPRO03 7 
AECLPRO03 8 
AECLPRO03 9 
AECLPR0 040 
AECLPRO04 1 
AECLPRO042 
AECLPRO043 
AECLPRO044 
AECLPRO045 
AECLPRO046 
AECLPRO04 7 
AECLPRO04 8 
AECLPRO049 
AECLPR0 050 
AECLPRO05 1 
AECLPRO052 
AECLPRO053 
AECLPNR054 
AECLPNR05 5 
AECLPRO056 
AECLPRO05 7 

AECLPNROO 1 4/7/95 

AECLPNR002 

AECLPNR003 

AECLPNR004 

AECLP NR 005 
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AECLPNR006 
AECLPNR007 
AECLPNR008 
AECLPNR009 
AECLPNR010 
AECLPNRO 1 1 
AECLPNR012 
AECLPROO 1 3 
AECLPROO 1 4 
AECLPROO 1 5 
AECLPROO 1 6 
AECLPROO 1 7 
AECLPROO 1 8 
AECLPROO 1 9 
AECLPRO02 0 
AECLPRO02 1 
AECLPRO022 
AECLPRO023 
AECLPRO024 
AECLPRO02 5 
AECLPRO026 
AECLPRO02 7 
AECLPRO02 8 
AECLPRO02 9 
AECLPRO03 0 
AECLPRO03 1 
AECLPRO032 
AECLPRO03 3 
AEC LPROO 3 4 
AECLPRO03 5 
AECLPRO03 6 
AECLPRO03 7 
AECLPRO03 8 
AECLPRO03 9 
AECLPR0 040 
AECLPRO04 1 
AECLPRO042 
AECLPRO043 
AECLPRO044 
AECLPRO045 
AECLPRO046 
AECLP RO 047 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 
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AECLPRO048 




N 


AECLPRO049 




N 


AEC LPROO 5 0 




N 


AECLPRO05 1 




N 


AEC LP RO O 5 2 




N 


AEC LP RO O 5 3 




N 


AECLPNR054 




N 


AECLPNR055 




N 


AEC LP RO O 5 6 




N 


AEC LP RO O 5 7 




N 



These test cases had to be re-executed because the include file CONSTANTS. FOR was changed in PR#24. 
























D.2 Pluto Test Case Results Log for ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


ARSP 


TEST CASE 
NAME 


’ROOOl.TC 


>_RO_002.TC 


’R0 003.TC 


’R0 004.TC 


’R0 005.TC 


’R0 006.TC 


’R0 007.TC 


’R0 008.TC 


’R0 009.TC 


’ROOIO.TC 


’NR011.TC 


’NR012.TC 


’NR013.TC 


’NR014.TC 


’NR015.TC 


’NR016.TC 


>_NR_017.TC 


’RO018.TC 


’RO019.TC 


’R0 020.TC 


’RO021.TC 


’NR 022.TC 


> NR 023. TC 


EXECUTION 

DATE 


1/5/95 


DATE 

CODE 

FETCHED 


12/21/94 


ARS PROO 0 1 . TC 


ARSPRO 002.TC 


ARS P RO O 0 3 . TC 


ARSPRO 004.TC 


ARS P RO O 0 5 . TC 


ARS P RO O 0 6 . TC 


ARS P RO O 0 7 . TC 


ARS P RO O 0 8 . TC 


ARS P RO O 0 9 . TC 


ARS P RO O 1 0 . TC 


ARSPNRO 1 1 .TC 


ARS P_NR_0 1 2 . TC 


ARSPNRO 1 3 .TC 


ARS P_NR_0 1 4 . TC 


ARSP NR 015. TC 


DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



Y 

24 


N 



N 



N 



N 



Y 

24 


Y 

24 

12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 
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ARSP NR 016. TC N 


ARSP NR 017. TC N 


ARSP RO 018. TC N 


ARSP RO 019. TC N 


ARSP RO 020. TC N 


ARSP RO 021.TC N 


ARSP NR 022. TC N 


ARSP NR 023. TC N 


ARSP RO 001. TC 4/7/95 4/6/95 4/6/95 N 


ARSP RO 002. TC N 


ARSP RO 003. TC N 


ARSP RO 004. TC N 


ARSP RO 005. TC N 


ARSP RO 006. TC N 


ARSP RO 007. TC N 


ARSP RO 008. TC N 


ARSP RO 009. TC N 


ARSP RO 010. TC N 


ARSP NR 011.TC N 


ARSP NR 012. TC N 


ARSP NR 013. TC N 


ARSP NR 014. TC N 


ARSP NR 015. TC N 


ARSP NR 016. TC N 


ARSP NR 017. TC N 


ARSP RO 018. TC N 


ARSP RO 019. TC N 


ARSP RO 020. TC N 


ARSP RO 021.TC N 


ARSP NR 022. TC N 


ARSP NR 023. TC N 
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DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 
























































































1/17/95 


12/21/94 


12/21/94 


ASPRO 039.TC 
ASPR0 040.TC 
ASPRO041 .TC 
ASPRO 042.TC 
ASPRO 043.TC 
ASP_RO_044.TC 
ASP_NR_001.TC 
ASP_NR_002.TC 
ASP_NR_003.TC 
ASP_NR_004.TC 
ASPNR 005.TC 
ASPNR 006.TC 
ASP_NR_007.TC 
ASPR0 008.TC 
ASPR0 009.TC 
ASPROOIO.TC 
ASPROO 1 1 .TC 
ASPROO 12. TC 
ASPRO013.TC 
ASPRO014.TC 
ASPRO015.TC 
ASPNR016.TC 
ASPRO017.TC 
ASPRO018.TC 
ASPRO019.TC 
ASPR0 020.TC 
ASPRO02 1 .TC 
ASPRO 022.TC 
ASPRO 023.TC 
ASPRO 024.TC 
ASPRO 025.TC 
ASPRO 026.TC 
ASPRO 027.TC 
ASPRO 028.TC 
ASPRO 029.TC 
ASPR0 030.TC 
ASPRO03 1 .TC 
ASPRO 032.TC 
ASPRO 033.TC 
ASPRO 034.TC 
ASPRO 035.TC 
ASPRO 036.TC 
ASPRO 037.TC 
ASP RO 038. TC 


N 

"n” 

"n” 

N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 



N* 
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ASPRO 039.TC 


ASPR0 040.TC 


ASPRO041 .TC 


ASPRO 042.TC 


ASPRO 043.TC 


ASP RO 044. TC 


ASPNR 


ASPNR 


ASPNR 


ASPNR 


ASPNR 


ASPNR 


ASPNR 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPNR 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASPRO 


ASP RO 


001. TC 


002. TC 


003. TC 


004. TC 


005. TC 


006. TC 


007. TC 


008. TC 


009. TC 


010. TC 


011.TC 


012. TC 


013. TC 


014. TC 


015. TC 


016. TC 


017. TC 


018. TC 


019. TC 


020. TC 


021. TC 


022. TC 


023. TC 


024. TC 


025. TC 


026. TC 


027. TC 


028. TC 


029. TC 


030. TC 


031. TC 


032. TC 


033. TC 


034. TC 


035. TC 


036. TC 


037. TC 


038. TC 


4/7/95 


4/6/95 



N* 



N* 



N* 



N* 



N* 



N* 


4/6/95 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



D-12 






























































































ASPRO 039.TC 




N 


ASPRO 040.TC 




N 


ASPRO04 1 . TC 




N 


ASPRO 042 . T C 




N 


ASPRO043 . T C 




N 


ASPRO 044 . T C 




N 



These test cases had to be re-executed because the include file CONSTANTS. FOR was changed in PR#24. 
















D.4 Pluto Test Case Results Log for CP 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

CPNR001.TC 

1/12/95 

12/28/94 

1/12/95 

Y 

25 

CPNR 002.TC 




Y 

25 

CPNR 003.TC 




Y 

25 

CPNR 004.TC 




Y 

25 

CPNR 005.TC 




Y 

25 

CPNR001.TC 

1/19/95 

1/19/95 

1/12/95 

N 


CPNR 002.TC 




N 


CPNR 003.TC 




N 


CPNR 004.TC 




N 


CPNR 005.TC 




N 


CPNR001.TC 

4/7/95 

4/6/95 

4/7/95 

N 


CPNR 002.TC 




N 


CPNR 003.TC 




N 


CPNR 004.TC 




N 


CPNR 005.TC 




N 
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D.5 Pluto Test Case Results Log for CRCP 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE 
TEST CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or 
N?) 

PR# 

CRCPNR001 

1/5/95 

12/21/94 

12/21/94 

N 


CRCPNR002 




N 


CRCPNR003 




N 


CRCPNR004 




N 


CRCPNR005 




N 


CRCPNR006 




N 


CRCPR0 007 




N 


CRCPR0 008 




N 


CRCPR0 009 




N 


CRCPROOIO 




N 


CRCPNR001 

1/17/95 

12/21/94 

12/21/94 

N* 


CRCPNR002 




N* 


CRCPNR003 




N* 


CRCPNR004 




N* 


CRCPNR005 




N* 


CRCPNR006 




N* 


CRCPR0 007 




N* 


CRCPR0 008 




N* 


CRCPR0 009 




N* 


CRCPROOIO 




N* 


CRCPNROO 1 

4/7/95 

4/6/94 

4/7/94 

N 


CRCPNR002 




N 


CRCPNR003 




N 


CRCPNR004 




N 


CRCPNR005 




N 


CRCPNR006 




N 


CRCPR0 007 




N 


CRCPR0 008 




N 


CRCPR0 009 




N 


CRCPROOIO 




N 



*: These test cases had to be re-executed because the include file CONSTANTS. FOR was changed in PR#24. 
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DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

1/4/95 

Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 























































































GPRO039 


GPR0 040 


GPRO04 1 


GPRO042 


GPRO043 


GPRO044 


GPRO045 


GPRO046 


GPRO047 


GPRO048 


GPRO049 


GPR0 050 


GPRO05 1 


GPRO052 


GPNR053 


GPRO054 


GPRO055 


GPRO056 


GPRO057 


GPRO058 


GPRO059 


GPR0 060 


GPRO06 1 


GPRO062 


GPRO063 


GPRO064 


GPRO065 


GPRO066 


GPRO067 


GPRO068 


GPRO069 


GPR0 070 


GPRO07 1 


GPRO072 


GPRO073 


GPRO074 


GPRO075 


GPRO076 


GPRO077 


GPRO078 


GPRO079 


GPR0 080 


GPRO081 


GP RO 082 



Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 
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Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 


Y 

24 

1/4/95+ 

N 


12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 
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GPROOll 


GPRO012 


GPRO013 


GPRO014 


GPRO015 


GPRO016 


GPRO017 


GPRO018 


GPRO019 


GPR0 020 


GPRO021 


GPRO022 


GPRO023 


GPRO024 


GPRO025 


GPRO026 


GPRO027 


GPRO028 


GPRO029 


GPR0 030 


GPRO03 1 


GPRO032 


GPRO033 


GPRO034 


GPRO035 


GPRO036 


GPRO037 


GPRO038 


GPRO039 


GPR0 040 


GPRO04 1 


GPRO042 


GPRO043 


GPRO044 


GPRO045 


GPRO046 


GPRO047 


GPRO048 


GPRO049 


GPR0 050 


GPRO05 1 


GPRO052 


GPNR053 


GP RO 054 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



D-19 




























































































GPRO055 


GPRO056 


GPRO057 


GPRO058 


GPRO059 


GPR0 060 


GPRO06 1 


GPRO062 


GPRO063 


GPRO064 


GPRO065 


GPRO066 


GPRO067 


GPRO068 


GPRO069 


GPR0 070 


GPRO07 1 


GPRO072 


GPRO073 


GPRO074 


GPRO075 


GPRO076 


GPRO077 


GPRO078 


GPRO079 


GPR0 080 


GPRO081 


GPRO082 


GPRO083 


GPRO084 


GPRO085 


GPRO086 


GPRO087 


GPRO088 


GPRO089 


GPR0 090 


GPRO09 1 


GPRO092 


GPRO093 


GPRO094 


GPRO095 


GPRO096 


GPRO097 


GP RO 098 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



D-20 




























































































GPRO099 


GPROIOO 


GPRO101 


GPNR102 


GPNR103 


GPNR104 


GPNR105 


GPNR106 


GPRO107 


GPRO108 


GPRO109 


GPROllO 


GPROlll 


GPR0112 


GPR0113 


GPR0114 


GPR0115 


GPR0116 


GPNROO 1 


GPNR002 


GPNR003 


GPNR004 


GPNR005 


GPNR006 


GPNR007 


GPNR008 


GPR0 009 


GPROOIO 


GPROOll 


GPRO012 


GPRO013 


GPRO014 


GPRO015 


GPRO016 


GPRO017 


GPRO018 


GPRO019 


GPR0 020 


GPRO021 


GPRO022 


GPRO023 


GPRO024 


GPRO025 


GP RO 026 


3/1/95 


1/13/95 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 


3/1/95 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



D-21 






























































































GPRO027 


GPRO028 


GPRO029 


GPR0 030 


GPRO03 1 


GPRO032 


GPRO033 


GPRO034 


GPRO035 


GPRO036 


GPRO037 


GPRO038 


GPRO039 


GPR0 040 


GPRO04 1 


GPRO042 


GPRO043 


GPRO044 


GPRO045 


GPRO046 


GPRO047 


GPRO048 


GPRO049 


GPR0 050 


GPRO05 1 


GPRO052 


GPNR053 


GPRO054 


GPRO055 


GPRO056 


GPRO057 


GPRO058 


GPRO059 


GPR0 060 


GPRO06 1 


GPRO062 


GPRO063 


GPRO064 


GPRO065 


GPRO066 


GPRO067 


GPRO068 


GPRO069 


GP RO 070 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



D-22 




























































































GPRO07 1 


GPRO072 


GPRO073 


GPRO074 


GPRO075 


GPRO076 


GPRO077 


GPRO078 


GPRO079 


GPR0 080 


GPRO081 


GPRO082 


GPRO083 


GPRO084 


GPRO085 


GPRO086 


GPRO087 


GPRO088 


GPRO089 


GPR0 090 


GPRO09 1 


GPRO092 


GPRO093 


GPRO094 


GPRO095 


GPRO096 


GPRO097 


GPRO098 


GPRO099 


GPROIOO 


GPRO101 


GPNR102 


GPNR103 


GPNR104 


GPNR105 


GPNR106 


GPRO107 


GPRO108 


GPRO109 


GPROllO 


GPROlll 


GPR0112 


GPR0113 


GP RO 114 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



D-23 




























































































GPR0115 


GPR0116 


GPNROO 1 


GPNR002 


GPNR003 


GPNR004 


GPNR005 


GPNR006 


GPNR007 


GPNR008 


GPR0 009 


GPROOIO 


GPROOll 


GPRO012 


GPRO013 


GPRO014 


GPRO015 


GPRO016 


GPRO017 


GPRO018 


GPRO019 


GPR0 020 


GPRO021 


GPRO022 


GPRO023 


GPRO024 


GPRO025 


GPRO026 


GPRO027 


GPRO028 


GPRO029 


GPR0 030 


GPRO03 1 


GPRO032 


GPRO033 


GPRO034 


GPRO035 


GPRO036 


GPRO037 


GPRO038 


GPRO039 


GPR0 040 


GPRO04 1 


GP RO 042 


4/6/95 



N 



N 


4/7/95 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



D-24 






























































































GPRO043 


GPRO044 


GPRO045 


GPRO046 


GPRO047 


GPRO048 


GPRO049 


GPR0 050 


GPRO05 1 


GPRO052 


GPNR053 


GPRO054 


GPRO055 


GPRO056 


GPRO057 


GPRO058 


GPRO059 


GPR0 060 


GPRO06 1 


GPRO062 


GPRO063 


GPRO064 


GPRO065 


GPRO066 


GPRO067 


GPRO068 


GPRO069 


GPR0 070 


GPRO07 1 


GPRO072 


GPRO073 


GPRO074 


GPRO075 


GPRO076 


GPRO077 


GPRO078 


GPRO079 


GPR0 080 


GPRO081 


GPRO082 


GPRO083 


GPRO084 


GPRO085 


GP RO 086 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 
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D.7 Pluto Test Case Results Log for GSP 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

GSPNR001.TC 

1/5/95 

12/21/94 

12/21/94 

N 


GSPR0 002.TC 




N 


GSPR0 003.TC 




N 


GSPR0 004.TC 




N 


GSPR0 005.TC 




N 


GSPR0 006.TC 




N 


GSPR0 007.TC 




N 


GSPR0 008.TC 




N 


GSPR0 009.TC 




N 


GSPNR001.TC 

1/17/95 

12/21/94 

12/21/94 

N* 


GSPR0 002.TC 




N* 


GSPR0 003.TC 




N* 


GSPR0 004.TC 




N* 


GSPR0 005.TC 




N* 


GSPR0 006.TC 




N* 


GSPR0 007.TC 




N* 


GSPR0 008.TC 




N* 


GSPR0 009.TC 




N* 


GSPNR001.TC 

4/7/95 

4/6/95 

4/6/95 

N 


GSPR0 002.TC 




N 


GSPR0 003.TC 




N 


GSPR0 004.TC 




N 


GSPR0 005.TC 




N 


GSPR0 006.TC 




N 


GSPR0 007.TC 




N 


GSPR0 008.TC 




N 


GSPR0 009.TC 




N 



*: These test cases had to be re-executed because the include file CONSTANTS. FOR was changed in PR#24. 
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D.8 Pluto Test Case Results Log for RECLP 


TEST CASE 
NAME 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


NR001 


NR_002 


NR_003 


NR_004 


NR_005 


NR_006 


NR_007 


NR_008 


NR_009 


NR_0 1 0 


NR_0 1 1 


NR_012 


NR_013 


NR_014 


NR_0 1 5 


NR_0 1 6 


NR_0 1 7 


NR_018 


NR_019 


NR_020 


NR_02 1 


NR_022 


NR_023 


NR_024 


NR_025 


NR_026 


NR_027 


NR_028 


NR_029 


NR_030 


NR_03 1 


NR_032 


NR_033 


NR_034 


NR_035 


NR_036 


NR_037 


NR_03 8 


NR_039 


NR_040 


NR 041 


EXECUTION 

DATE 


1/5/95 


DATE 

CODE 

FETCHED 


12/21/94 


DATE TEST 

RESULTS 

PR# 

CASE 

(was .ANA file 


FETCHED 

generated Y or N?) 


12/21/94 

N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 
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RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


RECLP 


NR_042 


NR_043 


NR_044 


NR_045 


NR046 


NR_047 


NR_048 


NR_049 


NR_050 


NR_05 1 


NR_052 


NR_053 


NR_054 


NR_055 


NR_056 


NR_057 


NR_058 


NR_059 


R0 060 


RO061 


RO062 


RO063 


NR_064 


NR_065 


NR066 


NR_067 


NR_068 


NR_001 


NR_002 


NR_003 


NR_004 


NR_005 


NR_006 


NR_007 


NR_008 


NR_009 


NR_0 1 0 


NR_0 1 1 


NR_012 


NR_013 


NR_0 1 4 


NR_0 1 5 


NR_016 


NR_017 


NR_018 


NR_019 


NR_020 


NR 021 



1/13/95 



N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 


N* 

24 

12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 
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RECLPNR022 
RECLPNR023 
RECLPNR024 
RECLPNR025 
RECLPNR026 
RECLPNR027 
RECLPNR028 
RECLPNR029 
RECLPNR030 
RECLPNR031 
RECLPNR032 
RECLPNR033 
RECLPNR034 
RECLPNR035 
RECLPNR036 
RECLPNR037 
RECLPNR038 
RECLPNR039 
RECLPNR040 
RECLPNR04 1 
RECLPNR042 
RECLPNR043 
RECLPNR044 
RECLP_NR_045 
RECLPNR046 
RECLPNR047 
RECLPNR048 
RECLPNR049 
RECLPNR050 
RECLPNR05 1 
RECLPNR052 
RECLPNR053 
RECLPNR054 
RECLP_NR_055 
RECLPNR056 
RECLPNR057 
RECLPNR058 
RECLPNR059 
RECLPR0 060 
RECLPRO06 1 
RECLPRO062 
RECLPRO063 
RECLPNR064 
RECLPNR065 
RECLPNR066 
RECLP NR 067 


RECLPNR068 

RECLP NR 001 4/7/95 
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RECLPNR002 
RECLP NR 003 
RECLP NR 004 
RECLPNR005 
RECLPNR006 
RECLPNR007 
RECLPNR008 
RECLPNR009 
RECLPNR010 
RECLPNROl 1 
RECLPNR012 
RECLPNR013 
RECLPNR014 
RECLPNRO 1 5 
RECLPNR016 
RECLPNR017 
RECLPNR018 
RECLPNR019 
RECLPNR020 
RECLPNR021 
RECLPNR022 
RECLPNR023 
RECLPNR024 
RECLP_NR_025 
RECLPNR026 
RECLPNR027 
RECLPNR028 
RECLPNR029 
RECLPNR030 
RECLPNR03 1 
RECLPNR032 
RECLPNR033 
RECLPNR034 
RECLPNR035 
RECLPNR036 
RECLPNR037 
RECLPNR038 
RECLPNR039 
RECLPNR040 
RECLPNR04 1 
RECLPNR042 
RECLPNR043 
RECLP_NR_044 
RECLPNR045 
RECLPNR046 
RECLPNR047 
RECLP_NR_048 
RECLP NR 049 


N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

N 

Nl 

N 

N 

N 

N 

N 

N 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

Nl 

N 
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RECLPNR050 




N 


RECLPNR05 1 




N 


RECLPNR052 




N 


RECLPNR053 




N 


RECLPNR054 




N 


RECLPNR055 




N 


RECLPNR056 




N 


RECLPNR057 




N 


RECLPNR058 




N 


RECLPNR059 




N 


RE C LPROO 6 0 




N 


RECLPRO06 1 




N 


RECLPRO062 




N 


RE C LPROO 6 3 




N 


RECLPNR064 




N 


RECLPNR065 




N 


RECLPNR066 




N 


RECLPNR067 




N 


RECLPNR068 




N 



Even though an analysis file (.ANA) was not generated for these test cases, the limits checking prints 
messages to the screen for values of THETA that are in bounds. This indicates an error in the bounds 
checking code. Further observations revealed that the upper and lower bounds constants were reversed in the 
CONST ANTS. FOR file. The test cases were re-executed after this is corrected. Note that neither the RECLP 
code or the test cases had to be refetched. However, the CONSTANTS. FOR file was refetched and the code 
was recompiled. 




D.9 Pluto Test Case Results Log for TDLRSP 


TEST CASE 
NAME 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


TDLRSP 


NR001.TC 


R0 002.TC 


NR 003.TC 


R0 004.TC 


NR 005.TC 


R0 006.TC 


NR 007.TC 


NR 008.TC 


NR 009.TC 


NR_010.TC 


NR_01 l.TC 


NR_012.TC 


NR013.TC 


NR014.TC 


NR015.TC 


NR016.TC 


NR_017.TC 


NR_018.TC 


NR019.TC 


NR 020.TC 


NR_021.TC 


RO 022.TC 


RO 023.TC 


RO 024.TC 


RO 025.TC 


RO 026.TC 


RO 027.TC 


RO 028. TC 


EXECUTION 

DATE 


1/4/95 


DATE 

CODE 

FETCHED 


12/21/94 


TDLRSPNROO l.TC 


TDLRSPR0 002.TC 


TDLRSPNR 003.TC 


TDLRSPR0 004.TC 


TDLRSPNR 005.TC 


TDLRSPR0 006.TC 


TDLRSPNR 007.TC 


TDLRSPNR 008.TC 


TDLRSPNR 009.TC 


TDLRSP NR 010. TC 


DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



N 



Y 

24 


N 



N 


12/21/94 

N 



N 



N 



N 



N 



N 



N 



N 



N 



N 
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TDLRSP NR Oll.TC N 


TDLRSP NR 012. TC N 


TDLRSP NR 013. TC N 


TDLRSP NR 014. TC N 


TDLRSP NR 015. TC N 


TDLRSP NR 016. TC N 


TDLRSP NR 017. TC N 


TDLRSP NR 018. TC N 


TDLRSP NR 019. TC N 


TDLRSP NR 020. TC N 


TDLRSP NR 021.TC N 


TDLRSP RO 022. TC N 


TDLRSP RO 023. TC N 


TDLRSP RO 024. TC N 


TDLRSP RO 025. TC N 


TDLRSP RO 026. TC Y* 


TDLRSP RO 027. TC N 


TDLRSP RO 028. TC N 


TDLRSP NR 001. TC 4/7/95 4/6/95 4/6/95 N 


TDLRSP RO 002. TC N 


TDLRSP NR 003. TC N 


TDLRSP RO 004. TC N 


TDLRSP NR 005. TC N 


TDLRSP RO 006. TC N 


TDLRSP NR 007. TC N 


TDLRSP NR 008. TC N 


TDLRSP NR 009. TC N 


TDLRSP NR 010. TC N 


TDLRSP NR Oll.TC N 


TDLRSP NR 012. TC N 


TDLRSP NR 013. TC N 


TDLRSP NR 014. TC N 


TDLRSP NR 015. TC N 


TDLRSP NR 016. TC N 


TDLRSP NR 017. TC N 


TDLRSP NR 018. TC N 


TDLRSP NR 019. TC N 


TDLRSP NR 020. TC N 


TDLRSP NR 021.TC N 


TDLRSP RO 022. TC N 


TDLRSP RO 023. TC N 


TDLRSP RO 024. TC N 


TDLRSP RO 025. TC N 


TDLRSP RO 026. TC Y* 
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TDLRSPRO02 7 .TC 




N 


TDLRSPRO 02 8 .TC 




N 



*: The ANA file generated in this iteration of testing involves a condition that is not specified in the 
SPEC. Although the results of this test run does not agree with the expected values, the results are just as 
valid because this robustness test case exercises a condition that is not defined in the Specification. More 
specifically, a value of "2" is assigned to the variable TDLRSTATE. Although a "2" is not defined as a 
legal value for this variable in the GCS Spec, it is a possible value since the variable is ultimately 
implemented as an integer. For robustness test cases, DO-178B requires only that the software not cause 
any detrimental effects to the system. For this specific test case, the PLUTO code leaves the values of 
KMATRIX unchanged. This will not have a severe impact on the implementation's ability to deliver the 
required function for TDLRSP. 
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D.10 Pluto Test Case Results Log for TDSP 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

TDSPNROO 1 .TC 

1/4/95 

12/21/94 

12/21/94 

N 


TDSPNR 002.TC 




N 


TDSPNR 003.TC 




N 


TDSPR0 004.TC 




N 


TDSPR0 005.TC 




N 


TDSPR0 006.TC 




N 


TDSPR0 007.TC 




N 


TDSPNROO 1 .TC 

1/17/95 

12/21/94 

12/21/94 

N* 


TDSPNR 002.TC 




N* 


TDSPNR 003.TC 




N* 


TDSPR0 004.TC 




N* 


TDSPR0 005.TC 




N* 


TDSPR0 006.TC 




N* 


TDSPR0 007.TC 




N* 


TDSPNROO 1 .TC 

4/7/95 

4/6/95 

4/6/95 

N 


TDSPNR 002.TC 




N 


TDSPNR 003.TC 




N 


TDSPR0 004.TC 




N 


TDSPR0 005.TC 




N 


TDSPR0 006.TC 




N 


TDSPR0 007.TC 




N 



*: These test cases had to be re-executed because the include file CONSTANTS. FOR was changed in PR#24. 
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D.ll Pluto Test Case Results Log for TSP 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

TSPNR001.TC 

1/4/95 

12/21/94 

12/21/94 

N 






N 






N 






N 






N 


TSPNR 006.TC 




Y 

24 





Y 

24 





Y 

24 





Y 

24 





Y 

24 

TSPROO 1 1 .TC 




Y 

24 


1/13/95 

1/13/95 

12/21/94 

N 






N 






N 






N 


TSPR0 005.TC 




N 






N 






N 






N 


TSPR0 009.TC 




N 






N 


TSPROOll.TC 




Y* 



4/7/95 

4/6/95 

4/6/95 

N 






N 


TSPNR003 .TC 




N 


TSPR0 004.TC 




N 






N 






N 






N 


TSPR0 008.TC 




N 


TSPR0 009.TC 




N 






N 


TSPROOll.TC 




Y* 



*: For this robustness test case, the difference flagged by the ANA file is in the 14th digit of 
ATMOSPHERIC TEMP. This amounts to a relative error less than that required by the simulator. 
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D.12 Pluto Test Case Results Log for SP Subframe 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

SP_001 

3/6/95 

1/13/95 

3/2/95 

N 


SP_001 

4/7/95 

4/6/95 

4/7/95 

N 



D.13 Pluto Test Case Results Log for GP Subframe 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

GPSF001. 

3/6/95 

1/13/95 

3/2/95 

N 


GPSF 002. 




N 


GPSF 003. 




N 


GPSF 004. 




N 


GPSF005 




N 


GPSF006 




N 


GPSF007 




N 


GPSF 008. 




N 


GPSF001. 

4/7/95 

4/6/95 

4/7/95 

N 


GPSF 002. 




N 


GPSF 003. 




N 


GPSF 004. 




N 


GPSF005 




N 


GPSF006 




N 


GPSF007 




N 


GPSF 008. 




N 
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D.14 Pluto Test Case Results Log for CLP Subframe 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

CLP 001 

3/6/95 

1/13/95 

3/2/95 

N 


CLP 002 




N 


CLP 003 




N 


CLP 004 




N 


CLP 005 




N 


CLP 006 




N 


CLP 007 




N 


CLP 008 




N 


CLP 009 




N 


CLP 010 




N 


CLP Oil 




N 


CLP 012 




N 


CLP 013 




N 


CLP 014 




N 


CLP 001 

4/7/95 

4/6/95 

4/7/95 

N 


CLP 002 




N 


CLP 003 




N 


CLP 004 




N 


CLP 005 




N 


CLP 006 




N 


CLP 007 




N 


CLP 008 




N 


CLP 009 




N 


CLP 010 




N 


CLP Oil 




N 


CLP 012 




N 


CLP 013 




N 


CLP 014 




N 
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D.15 Pluto Test Case Results Log for FRAME 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

RESULTS 
(was .ANA file 
generated Y or N?) 

PR# 

FRAME001 

3/6/95 

1/13/95 

3/2/95 

N 


FRAME_002 






FRAME003 






FRAME_004 






FRAME_005 






FRAME_006 






FRAME007 






FRAME_008 






FRAME009 






FRAME_00 1 

4/7/95 

4/6/95 

4/7/95 

N 


FRAME_002 






FRAME_003 






FRAME004 






FRAME_005 






FRAME_006 






FRAME_007 






FRAME_008 






FRAME_009 






FRAME_009 
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D.16 Pluto Test Case Results Log for Trajectory 


TEST CASE 
NAME 

EXECUTION 

DATE 

DATE 

CODE 

FETCHED 

DATE TEST 
CASE 
FETCHED 

TRAJATMUD/ICOO 1 

3/6/95 

3/6/95 

3/6/95 


TRAJATMUD/IC002 


TRAJATMUD/IC003 


TRAJATMUD/IC004 


TRAJATMUD/IC005 


TRAJATMUD/IC006 


TRAJATMUD/IC007 


TRAJATMUD/IC008 


TRAJATMUD/IC009 


TRAJATMUD/ICO 1 0 


TRAJATMUD/ICO 1 1 


TRAJATMUD/ICO 12 


TRAJTDUD/ICO 1 3 


TRAJTDUD/ICO 1 4 


TRAJTDUD/ICO 1 5 


TRAJTDUD/ICO 1 6 


TRAJTDUD/ICO 1 7 


TRAJTDUD/ICO 1 8 


TRAJTDUD/ICO 1 9 


TRAJTDUD/IC02 0 


TRAJTDUD/IC02 1 


TRAJTDUD/IC022 


TRA JTDUD/IC02 3 


TRAJTDUD/IC024 


TRAJTDUD/IC02 5 


TRA JTDUD/IC02 6 


TRAJTDUD/IC02 7 


TRA JTDUD/IC02 8 


TRAJTDUD/IC029 


TRAJTDUD/IC03 0 


TRAJTDUD/IC03 1 


TRA JTDUD/ICO 3 2 


TRAJTDUD/IC03 3 


TRA JTDUD/ICO 3 4 


TRAJATMUD/ICOO 1 


TRAJATMUD/IC002 


TRAJATMUD/IC003 


TRAJATMUD/IC004 


TRAJATMUD/IC005 


TRAJATMUD/IC006 


TRAJ ATM UD/IC 007 



RESULTS 

MATCHED 

EXPECTED 

FRAMES 

GPPHASE 
= 5 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

N 

Y 

Y 

Y 

Y 

3 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 
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TRAJATMUD/IC008 




Y 

Y 


TRAJATMUD/IC009 




Y 

Y 


TRAJATMUD/ICO 1 0 




Y 

Y 


TRAJATMUD/ICO 1 1 




Y 

Y 


TRAJATMUD/ICO 12 




Y 

Y 


TRAJTDUD/ICO 1 3 




Y 

Y 


TRAJTDUD/ICO 1 4 




Y 

Y 


TRAJTDUD/ICO 1 5 




Y 

Y 


TRAJTDUD/ICO 1 6 




Y 

Y 


TRAJTDUD/ICO 1 7 




Y 

Y 


TRAJTDUD/ICO 1 8 




Y 

Y 


TRAJTDUD/ICO 1 9 




Y 

Y 


TRAJTDUD/IC020 




Y 

Y 


TRAJTDUD/IC02 1 




Y 

Y 


TRAJTDUD/IC022 




Y 

Y 


TRAJTDUD/IC023 




Y 

Y 


TRAJTDUD/IC024 




Y 

Y 


TRAJTDUD/IC025 




Y 

Y 


TRAJTDUD/IC026 




Y 

Y 


TRAJTDUD/IC02 7 




Y 

Y 


TRAJTDUD/IC028 




Y 

Y 


TRAJTDUD/IC029 




Y 

Y 


TRAJTDUD/IC03 0 




Y 

Y 


TRAJTDUD/IC03 1 




Y 

Y 


TRA JTDUD/ICO 3 2 




Y 

Y 


TRAJTDUD/IC03 3 




Y 

Y 


TRA JTDUD/ICO 3 4 




Y 

Y 
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